Por que o nano não salva: permissão negada

Por que o nano não grava o seu ficheiro

O nano não grava o seu ficheiro por uma de quatro razões: não é o proprietário do ficheiro, o diretório pai não permite a operação que o nano está a tentar executar, o sistema de ficheiros está montado como somente leitura ou não tem espaço, ou está dentro de um contentor em execução com um ID de utilizador diferente. As duas primeiras são problemas de permissões, e as duas últimas não são. Verifique-as por esta ordem, porque a primeira razão abrange a maioria dos casos, é confirmada com um comando e a correção é sudoedit em vez de sudo nano.

Nada se perde enquanto o editor continua aberto. O seu texto permanece na memória, por isso pode deixar o ficheiro aberto, gravar o buffer num caminho que lhe pertença e colocá-lo no local correto depois. Essa alternativa é apresentada perto do final deste guia.

Execute estas verificações antes de alterar permissões

Aponte cada comando para o caminho real que está a editar. Eles respondem a perguntas diferentes, por isso execute todos antes de alterar qualquer coisa. Alterar permissões antes de saber qual verificação está a falhar normalmente cria um segundo problema além do primeiro.

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 mostra o ID do utilizador e os IDs dos grupos que tem neste momento. ls -l mostra o proprietário, o grupo e os bits de permissão do próprio ficheiro. ls -ld mostra os mesmos dados do diretório que o contém, que é uma pergunta diferente com uma resposta diferente. namei -l percorre todas as partes do caminho e lista o proprietário e as permissões de cada uma, respondendo às duas perguntas numa única saída. findmnt identifica o sistema de ficheiros associado a esse caminho e as opções com que foi montado. df -h indica o espaço livre e df -i indica os inodes livres, que podem esgotar-se independentemente do espaço. Se estas cadeias de permissões ainda não lhe forem familiares, comece por como ler a cadeia de permissões apresentada por ls -l.

Causa 1: o ficheiro pertence a root e a sua conta não

As permissões de leitura e escrita são independentes, e a maioria dos ficheiros em /etc pode ser lida por todos. Por isso, o nano abre o ficheiro, mostra o conteúdo e permite escrever livremente: nada disso altera o disco. A recusa ocorre ao guardar, quando o kernel compara o ID do seu utilizador e os IDs dos seus grupos com o proprietário, o grupo e os bits de outros utilizadores definidos no ficheiro. O nano apenas apresenta a resposta do kernel, por isso nenhuma opção do nano altera o resultado.

id e ls -l resolvem a questão em conjunto. O ficheiro pertence a root, a sua conta não é root e os bits de outros utilizadores não concedem permissão de escrita. Premir Ctrl-O novamente não ajuda.

Por que sudoedit é a forma correta de editar um ficheiro pertencente a root

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

sudo cria uma cópia temporária do ficheiro com o proprietário definido como o seu utilizador, executa nano nessa cópia com a sua própria conta e, depois de o editor terminar, copia o resultado para o local original com privilégios de root. O editor nunca é executado como root. sudo -e é o mesmo comando com outro nome. O editor é escolhido a partir de SUDO_EDITOR, depois de VISUAL e, por fim, de EDITOR, pelo que definir export EDITOR=nano no perfil da shell torna essa escolha a predefinição em todo o lado. Se o seu ficheiro sudoers tiver a flag env_editor desativada, essas variáveis são ignoradas e o editor é obtido da definição editor no sudoers.

sudo nano também permite guardar o ficheiro, e esse é o problema. Concede a um editor interativo completo privilégios de root sobre todo o sistema de ficheiros enquanto a sessão estiver ativa. Assim, um caminho introduzido incorretamente no pedido para guardar pode escrever o seu texto sobre um ficheiro de sistema diferente, como root. Trabalhar como um utilizador normal que chama sudo apenas nos passos que precisam dele é o hábito que deve criar, e sudoedit é a forma como esse hábito se aplica ao editar um ficheiro de configuração.

Duas regras do sudoedit surpreendem muitos utilizadores. O comando recusa editar um link simbólico e recusa editar um ficheiro dentro de um diretório onde o utilizador pode escrever, exceto quando o utilizador é root. A segunda regra existe porque qualquer pessoa com permissões de escrita no diretório pode substituir o ficheiro enquanto o editor está aberto. Ambos os comportamentos são as predefinições do sudoers (sudoedit_follow desativada, sudoedit_checkdir ativada). Um ficheiro que ainda não exista é criado para si.

Causa 2: o que o diretório pai realmente controla

As orientações destinadas a outros editores dizem que é necessária permissão de escrita no diretório para guardar um ficheiro, porque muitos editores guardam escrevendo um ficheiro novo e mudando o nome dele para substituir o antigo. O nano não funciona dessa forma. Abre o ficheiro indicado e escreve nesse próprio ficheiro. Por isso, quando o ficheiro já existe, o bit de escrita do diretório nunca é consultado.

O diretório continua a controlar outras operações. É por isso que ls -ld aparece na lista de verificações:

• Criar um ficheiro que ainda não existe requer permissões de escrita e execução no diretório, porque é necessário adicionar-lhe um nome novo. A sua umask define as permissões iniciais desse novo ficheiro.
• Aceder ao ficheiro requer permissão de execução, também chamada permissão de pesquisa, em todos os diretórios do caminho. Se faltar essa permissão num diretório, tudo o que estiver abaixo dele fica inacessível. namei -l mostra qual é esse diretório.
• Guardar com cópias de segurança ou com o bloqueio de ficheiros ativado escreve um segundo ficheiro junto do original. Por isso, estas funcionalidades requerem um diretório com permissão de escrita. As cópias de segurança são controladas pela opção -B ou por set backup num nanorc. O bloqueio é controlado por -G ou set locking. Ambas as funcionalidades estão desativadas, exceto se você ou a sua distribuição as tiverem ativado.

As permissões dos diretórios também têm o mesmo peso noutras partes do sistema. O servidor SSH recusa uma chave quando o seu diretório pessoal ou o diretório .ssh pode ser escrito por outros utilizadores. Esta é uma causa comum de o SSH rejeitar a sua chave durante o início de sessão.

Como o nano escreve no ficheiro que já existe, o ficheiro mantém o seu inode, que é a identidade do ficheiro no disco por trás do nome. Qualquer processo que mantenha o ficheiro aberto continua a acompanhá-lo, e um único ficheiro montado com bind num contentor continua a funcionar. Os editores que guardam substituindo o ficheiro quebram essa montagem, porque a montagem segue o inode, não o nome.

Causa 3: o sistema de ficheiros é só de leitura ou ficou sem espaço

findmnt no relatório de ro nas opções significa que a escrita nunca iria funcionar. O sistema de ficheiros pode ter sido montado dessa forma, através de /etc/fstab ou de uma montagem bind só de leitura. Também pode ter sido remontado como só de leitura pelo kernel depois de um erro de disco. O segundo caso é o mais grave. sudo dmesg -T | tail -50 mostra os erros de entrada/saída e do sistema de ficheiros que causaram a remontagem. A correção consiste em verificar o sistema de ficheiros enquanto ele está desmontado. Numa VPS, isso significa arrancar a consola de recuperação do fornecedor.

Um sistema de ficheiros cheio falha na mesma escrita por outro motivo. df -h abrange o caso normal. df -i abrange o caso que costuma passar despercebido: os inodes vêm de um conjunto fixo criado quando o sistema de ficheiros foi criado, e uma árvore com ficheiros pequenos pode consumi-los todos enquanto df -h ainda mostra gigabytes livres. Quando o espaço acaba e nada óbvio o está a ocupar, df e du discordam sobre um disco cheio aborda o caso de um ficheiro eliminado mas ainda aberto que causa o problema.

Há um detalhe que explica um sintoma confuso neste caso. O ext4 reserva uma parte dos blocos para o root quando o sistema de ficheiros é criado. Por isso, o root continua a escrever depois de os utilizadores normais serem impedidos. sudo parece então resolver o problema, o disco enche até ao fim e o problema regressa de forma mais grave.

Como o nano trunca o ficheiro antes de escrever o novo conteúdo, uma escrita que fique sem espaço a meio pode deixar o ficheiro mais curto do que estava. Faça uma cópia de uma configuração importante antes de a editar num sistema de ficheiros quase cheio. sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak mantém o proprietário, o grupo e as permissões na cópia.

Causa 4: está num contentor a editar um bind mount

A propriedade dos ficheiros é numérica. O kernel guarda um ID de utilizador, e o nome apresentado vem do componente /etc/passwd que faz a consulta. Por isso, o mesmo ficheiro pode apresentar um nome no host e outro nome, ou apenas um número, dentro do contentor. Compare os números, não os nomes: execute id -u dentro do contentor e ls -ln no ficheiro.

Um ficheiro montado por bind mantém a propriedade que tem no host. Quando o ficheiro no host pertence ao seu utilizador e o processo do contentor é executado por outro utilizador, a escrita é recusada dentro do contentor. Além disso, sudo dentro do contentor não altera o proprietário no host. Corrija o problema a partir do host, definindo como proprietário o ID com que o contentor é executado, ou execute o contentor com o ID que já é proprietário dos ficheiros. As imagens de linuxserver.io e de projetos semelhantes disponibilizam as variáveis PUID e PGID, que definem o utilizador com que o processo é executado.

Há mais dois casos de contentores que deve conhecer. Uma montagem definida como somente leitura com :ro, ou um contentor iniciado com --read-only, recusa escritas independentemente da propriedade. O comando cat /proc/mounts dentro do contentor mostra essa opção. Com o Podman rootless, um namespace de utilizadores mapeia os IDs de utilizador do contentor para um intervalo de IDs no host. Assim, um ficheiro que parece pertencer a root dentro do contentor pertence à sua conta sem privilégios fora dele.

Também pode ocorrer uma edição que funciona e desaparece depois. Um ficheiro alterado dentro de um contentor, num caminho que não é uma montagem, fica na camada gravável desse contentor. Essa camada é eliminada quando o contentor é recriado. Altere o ficheiro no lado do host da montagem ou durante a criação da imagem, se a alteração tiver de ser permanente.

A alternativa segura: guardar num caminho que lhe pertence

Não tente obter privilégios dentro do editor. Prima Ctrl-O, limpe o caminho apresentado na prompt, introduza um caminho dentro do seu diretório pessoal, como /home/you/nginx.conf.new, e prima Enter. Em seguida, prima Ctrl-X para sair. O seu trabalho está agora no disco, pertence-lhe, e o restante é uma cópia normal de ficheiro.

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

Use cp aqui em vez de mv. cp escreve através do ficheiro que já está no local, por isso esse ficheiro mantém o proprietário, o grupo e as permissões. mv, no mesmo sistema de ficheiros, substitui-o pelo seu ficheiro. Isso deixa um ficheiro de configuração em /etc pertencente à sua conta de utilizador, criando o próximo problema de permissões que terá de resolver.

Verifique o resultado com a ferramenta responsável pelo ficheiro antes de recarregar qualquer serviço. sudo nginx -t analisa a configuração do nginx, e sudo sshd -t analisa a configuração do servidor SSH. Dois ficheiros têm editores próprios que executam todo este procedimento: sudo visudo para /etc/sudoers e crontab -e para os seus próprios cron jobs. Cada um edita uma cópia temporária, verifica a sintaxe e instala o ficheiro apenas se a análise for bem-sucedida.

FAQ

Devo usar sudo nano ou sudoedit para editar um ficheiro do sistema?

Use sudoedit. O comando copia o ficheiro para uma cópia temporária pertencente ao seu utilizador, executa o editor com o seu utilizador e escreve o resultado de volta como root quando o editor termina. Assim, o próprio editor nunca tem privilégios de root. Defina SUDO_EDITOR, VISUAL ou EDITOR como nano para escolher o nano. sudo nano também funciona, mas dá a um editor interativo acesso de root a todos os caminhos do sistema durante a sessão. Um nome de ficheiro introduzido incorretamente no prompt de gravação pode, nesse caso, danificar um ficheiro do sistema.

Preciso de permissão de escrita no diretório para guardar um ficheiro com o nano?

Não, se o ficheiro já existir. O nano escreve no próprio ficheiro, por isso o kernel verifica o bit de escrita do ficheiro e o bit de execução em todos os diretórios do caminho. O bit de escrita do diretório é relevante quando o ficheiro ainda não existe, porque é necessário criar um nome novo, e quando as cópias de segurança ou o bloqueio de ficheiros estão ativados, porque ambos escrevem um segundo ficheiro junto do original.

O proprietário está correto e o disco não está cheio. O que mais pode impedir a escrita?

Há quatro possibilidades. O sistema de ficheiros pode estar montado como só de leitura, como mostra findmnt -no OPTIONS -T /etc/nginx/nginx.conf. O ficheiro pode ter o atributo immutable, como mostra lsattr e remove sudo chattr -i. Nem mesmo root pode escrever no ficheiro enquanto esse atributo estiver definido. O conjunto de inodes pode estar esgotado enquanto ainda existe espaço livre, como mostra df -i. O SELinux ou o AppArmor podem negar a escrita mesmo quando os bits de permissão a permitem. O log de auditoria regista a negação associada ao caminho que tentou escrever.

Onde guardo as alterações quando o ficheiro não pode ser guardado de todo?

Prima Ctrl-O e indique um caminho que pertença ao seu utilizador, dentro do seu diretório pessoal ou noutro local onde tenha permissão de escrita. O buffer continua na memória, por isso nada do que escreveu se perde. Depois, copie o ficheiro guardado para o local correto com sudo cp. Este comando mantém o proprietário e as permissões do ficheiro original. Em seguida, valide-o com o comando de teste do próprio serviço antes de recarregar o serviço.

Porque desaparecem as minhas alterações dentro de um contentor Docker?

Quando o caminho não é um mount, a alteração fica na camada de escrita desse contentor. Essa camada é eliminada quando o contentor é substituído. Edite o ficheiro no lado do host de um bind mount ou de um volume, ou inclua-o na imagem. Quando o caminho é um bind mount e a gravação é recusada, compare id -u dentro do contentor com o proprietário numérico obtido por ls -ln. O ficheiro mantém o proprietário definido no host, e o processo do contentor tem de corresponder a esse proprietário.