nano non salva: errore Permission denied, cosa fare

Perché nano non salva il file

nano non salva il file per uno di quattro motivi: non sei il proprietario del file, la directory padre non consente l'operazione che nano sta tentando di eseguire, il filesystem è di sola lettura o non ha spazio disponibile, oppure ti trovi all'interno di un container eseguito con un ID utente diverso. I primi due sono problemi di permessi, gli ultimi due no. Verificali in questo ordine, perché il primo motivo copre la maggior parte dei casi, si conferma con un solo comando e la relativa correzione è sudoedit invece di sudo nano.

Finché l'editor è ancora aperto, non perdi nulla. Il testo resta in memoria, quindi puoi lasciare aperto il file, scrivere il buffer in un percorso di cui sei proprietario e sostituire il file originale in un secondo momento. Questa procedura di recupero è descritta verso la fine della guida.

Esegui questi controlli prima di modificare qualsiasi autorizzazione

Indica a ogni comando il percorso effettivo che stai modificando. I comandi rispondono a domande diverse, quindi eseguili tutti prima di intervenire. Modificare le autorizzazioni prima di sapere quale controllo non passa crea spesso un secondo problema oltre al primo.

id
ls -l /etc/nginx/nginx.conf
ls -ld /etc/nginx
namei -l /etc/nginx/nginx.conf
findmnt -no SOURCE,FSTYPE,OPTIONS -T /etc/nginx/nginx.conf
df -h /etc/nginx
df -i /etc/nginx

id stampa l'ID utente e gli ID dei gruppi associati alla sessione corrente. ls -l mostra il proprietario, il gruppo e i bit delle autorizzazioni del file. ls -ld mostra gli stessi dati per la directory che lo contiene, che è una verifica distinta con un risultato distinto. namei -l percorre ogni componente del percorso ed elenca il proprietario e le autorizzazioni di ciascuna, quindi fornisce entrambe le informazioni in un unico output. findmnt indica il filesystem utilizzato per quel percorso e le opzioni con cui è stato montato. df -h riporta lo spazio libero, mentre df -i riporta gli inode disponibili, che possono esaurirsi indipendentemente dallo spazio. Se queste stringhe delle autorizzazioni non ti sono ancora familiari, inizia da come leggere la stringa delle autorizzazioni stampata da ls -l.

Causa 1: il file appartiene a root e l'utente corrente non dispone dei relativi permessi

I permessi di lettura e scrittura sono distinti e la maggior parte dei file in /etc è leggibile da tutti. Per questo nano apre il file, ne mostra il contenuto e consente di digitare liberamente: nessuna di queste operazioni modifica il disco. Il rifiuto si verifica al momento del salvataggio, quando il kernel confronta l'ID utente e gli ID dei gruppi con il proprietario, il gruppo e i bit relativi agli altri utenti del file. nano riporta ciò che comunica il kernel, quindi nessuna opzione di nano può modificare il risultato.

id e ls -l lo confermano. Il file appartiene a root, l'utente corrente non è root e i bit relativi agli altri utenti non concedono il permesso di scrittura. Premere di nuovo Ctrl-O non risolverà il problema.

Perché sudoedit è il modo corretto per modificare un file di proprietà di root

SUDO_EDITOR=nano sudoedit /etc/nginx/nginx.conf

sudo crea una copia temporanea del file e ne imposta la proprietà a tuo nome, esegue nano su quella copia con il tuo utente, quindi sostituisce il file originale con il risultato usando i privilegi di root quando l’editor termina. L’editor non viene mai eseguito come root. sudo -e è lo stesso comando con un nome diverso. L’editor viene scelto prima da SUDO_EDITOR, poi da VISUAL e infine da EDITOR; quindi impostare export EDITOR=nano nel profilo della shell rende questa scelta predefinita ovunque. Se nei sudoers il flag env_editor è disattivato, queste variabili vengono ignorate e l’editor viene invece determinato dall’impostazione editor nei sudoers.

sudo nano salva anch’esso il file, ed è questo il problema. Concede a un editor interattivo completo i privilegi di root sull’intero filesystem per tutta la durata della sessione. Di conseguenza, un percorso digitato in modo errato alla richiesta di salvataggio può sovrascrivere un altro file di sistema con i privilegi di root. L’abitudine da sviluppare è lavorare come utente normale che usa sudo solo per le operazioni che richiedono privilegi; sudoedit applica questa abitudine quando modifichi un file di configurazione.

Due regole di sudoedit sorprendono molti utenti. Il comando rifiuta di modificare un collegamento simbolico e rifiuta di modificare un file contenuto in una directory su cui hai permessi di scrittura, a meno che tu non sia root. La seconda regola esiste perché chiunque possa scrivere nella directory può sostituire il file mentre l’editor è aperto. Entrambi i comportamenti sono predefiniti in sudoers (sudoedit_follow disattivato, sudoedit_checkdir attivato). Se il file non esiste ancora, viene creato.

Causa 2: cosa controlla effettivamente la directory padre

Le indicazioni scritte per altri editor affermano che per salvare serve il permesso di scrittura sulla directory, perché molti editor salvano scrivendo un nuovo file e rinominandolo sopra quello precedente. nano non funziona in questo modo. Apre il file indicato e scrive direttamente in quel file. Di conseguenza, se il file esiste già, il bit di scrittura della directory non viene mai verificato.

La directory continua a controllare altri aspetti. Per questo ls -ld è incluso nell'elenco dei controlli:

• Creare un file che non esiste ancora richiede i permessi di scrittura ed esecuzione sulla directory, perché è necessario aggiungere un nuovo nome alla directory. Il tuo umask determina i permessi iniziali del nuovo file.
• Per raggiungere il file servono i permessi di esecuzione, chiamati anche permessi di ricerca, su ogni directory del percorso. Se una directory ne è priva, tutto ciò che si trova al suo interno diventa inaccessibile e namei -l mostra quale directory è coinvolta.
• Il salvataggio con i backup o con il blocco dei file attivato scrive un secondo file accanto all'originale. Queste funzioni richiedono quindi una directory scrivibile. I backup sono l'opzione -B oppure set backup in un nanorc, mentre il blocco è -G oppure set locking. Entrambe le funzioni sono disattivate, a meno che tu o la tua distribuzione non le abbiate attivate.

I permessi delle directory hanno la stessa importanza anche in altre parti del sistema. Il server SSH rifiuta una chiave quando la directory home o la directory .ssh può essere modificata da altri utenti. Questa è una causa comune del rifiuto della chiave SSH al momento dell'accesso.

Poiché nano scrive nel file già esistente, il file conserva il proprio inode, cioè l'identità del file sul disco associata al nome. Qualsiasi processo che mantiene aperto il file continua a seguirlo, e un singolo file montato tramite bind in un container continua a funzionare. Gli editor che salvano sostituendo il file interrompono questo montaggio, perché il mount segue l'inode e non il nome.

Cause 3: the filesystem is read only, or it has nothing left

findmnt reporting ro in the options means the write was never going to succeed. Either the filesystem was mounted that way, through /etc/fstab or a read only bind mount, or the kernel remounted it read only after a disk error. The second case is the serious one. sudo dmesg -T | tail -50 shows the input/output and filesystem errors that led to the remount, and the repair is a filesystem check while it is unmounted, which on a VPS means booting the provider's rescue console.

A full filesystem fails the same write for a different reason. df -h covers the ordinary case. df -i covers the case people miss: inodes come from a fixed pool created when the filesystem was made, and a tree of tiny files can use them all while df -h still shows free gigabytes. When space is gone and nothing obvious is holding it, df and du disagreeing about a full disk covers the deleted-but-still-open file that causes it.

One detail explains a confusing symptom here. ext4 reserves a share of its blocks for root when the filesystem is created, so root keeps writing after ordinary users are refused. sudo then looks like the fix, the disk fills the rest of the way, and the problem returns in a worse form.

Because nano truncates the file before writing the new contents, a write that runs out of space partway can leave the file shorter than it was. Copy a config you care about before editing it on a filesystem that is nearly full. sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak keeps the owner, group and permissions on the copy.

Causa 4: stai modificando un bind mount dall'interno di un container

La proprietà dei file è numerica. Il kernel memorizza un ID utente e il nome visualizzato dipende da quale /etc/passwd esegue la ricerca. Di conseguenza, lo stesso file può mostrare un nome sull'host e un nome diverso, oppure soltanto un numero, all'interno del container. Confronta gli ID numerici invece dei nomi: esegui id -u nel container e ls -ln sul file.

Un file montato tramite bind mantiene la proprietà che ha sull'host. Se il file sull'host appartiene al tuo utente e il processo nel container viene eseguito da un utente diverso, la scrittura nel container viene rifiutata. Inoltre, sudo eseguito nel container non modifica il proprietario sull'host. Correggi il problema dall'host impostando come proprietario l'ID con cui viene eseguito il container, oppure esegui il container con l'ID che possiede già i file. Le immagini di linuxserver.io e di progetti simili espongono le variabili PUID e PGID che impostano l'utente con cui viene eseguito il processo.

È utile conoscere altri due casi relativi ai container. Un mount reso di sola lettura con :ro o un container avviato con --read-only rifiuta le scritture indipendentemente dalla proprietà. cat /proc/mounts eseguito nel container mostra il flag. Con rootless Podman, uno user namespace associa gli ID utente del container a un intervallo di ID sull'host. Di conseguenza, un file che nel container sembra appartenere a root appartiene all'esterno all'account non privilegiato dell'utente.

Esiste anche il caso della modifica che riesce e poi scompare. Un file modificato all'interno di un container, in un percorso che non è un mount, risiede nel writable layer del container. Questo layer viene eliminato quando il container viene ricreato. Modifica il file sul lato host del mount oppure nella build dell'immagine se la modifica deve essere permanente.

La via d’uscita: salvalo in un percorso di tua proprietà

Non cercare di ottenere privilegi dall’editor. Premi Ctrl-O, cancella il percorso richiesto, inserisci un percorso nella tua home directory, ad esempio /home/you/nginx.conf.new, e premi Invio. Poi premi Ctrl-X per uscire. Il file è ora salvato su disco, appartiene a te e il resto consiste in una normale copia di file.

sudo cp /home/you/nginx.conf.new /etc/nginx/nginx.conf
sudo nginx -t

Qui usa cp invece di mv. cp scrive nel file già presente, quindi il file conserva proprietario, gruppo e permessi. mv, se usato sullo stesso filesystem, lo sostituisce con il tuo file. In questo modo la configurazione in /etc appartiene al tuo account utente e diventa il successivo problema di permessi da risolvere.

Controlla il risultato con lo strumento che gestisce il file prima di ricaricare qualsiasi configurazione. sudo nginx -t analizza la configurazione di nginx e sudo sshd -t analizza la configurazione del server SSH. Due file dispongono di editor dedicati che eseguono automaticamente l’intera procedura: sudo visudo per /etc/sudoers e crontab -e per i tuoi cron job. Ciascun editor modifica una copia temporanea, verifica la sintassi e installa il file solo se l’analisi ha esito positivo.

FAQ

Devo usare sudo nano o sudoedit per modificare un file di sistema?

Usa sudoedit. Copia il file in una copia temporanea di tua proprietà, avvia l'editor con il tuo utente e riscrive il risultato come root quando l'editor termina. In questo modo l'editor non dispone mai dei privilegi di root. Imposta SUDO_EDITOR, VISUAL o EDITOR su nano per selezionare nano. Anche sudo nano funziona, ma concede a un editor interattivo l'accesso come root a tutti i percorsi del sistema per l'intera durata della sessione. Un solo nome file digitato in modo errato al prompt di salvataggio può quindi danneggiare un file di sistema.

Devo disporre dell'autorizzazione di scrittura sulla directory per salvare un file con nano?

Non per un file già esistente. nano scrive direttamente nel file, quindi il kernel controlla il bit di scrittura del file e il bit di esecuzione di ogni directory lungo il percorso. Il bit di scrittura della directory è necessario quando il file non esiste ancora, perché deve essere creato un nuovo nome. È necessario anche quando sono attivi i backup o il blocco dei file, perché entrambe le funzioni scrivono un secondo file accanto all'originale.

Il proprietario è corretto e il disco non è pieno. Cos'altro può impedire la scrittura?

Quattro elementi. Il filesystem potrebbe essere montato in sola lettura; findmnt -no OPTIONS -T /etc/nginx/nginx.conf lo mostra. Il file potrebbe avere l'attributo immutable; lsattr lo mostra e sudo chattr -i lo rimuove. Finché l'attributo è impostato, neppure root può scrivere nel file. Il pool di inode potrebbe essere esaurito anche se è ancora disponibile spazio libero; df -i lo mostra. SELinux o AppArmor possono negare la scrittura anche se i bit dei permessi la consentono. Il log di audit registra il rifiuto associato al percorso su cui hai tentato di operare.

Dove salvo le modifiche se il file non viene salvato in alcun modo?

Premi Ctrl-O e specifica un percorso di tua proprietà, nella tua home directory o in qualsiasi altra posizione in cui il tuo utente possa scrivere. Il buffer è ancora in memoria, quindi nulla di ciò che hai digitato viene perso. Copia poi il file salvato nella posizione corretta con sudo cp, che mantiene il proprietario e i permessi del file originale. Verifica quindi il file con il comando di test previsto dal servizio prima di ricaricare il servizio.

Perché le modifiche apportate in un container Docker scompaiono?

Quando il percorso non è un mount, la modifica viene scritta nel writable layer del container. Questo layer viene eliminato quando il container viene sostituito. Modifica il file sul lato host di un bind mount o di un volume, oppure includilo nell'immagine. Se il percorso è un bind mount e il salvataggio viene invece rifiutato, confronta id -u all'interno del container con il proprietario numerico restituito da ls -ln. Il file mantiene la proprietà dell'host e il processo nel container deve usare lo stesso proprietario.