Permission denied numa aplicação Node.js ou Python no cPanel: donos, modos e pastas

EACCES: permission denied no Node.js, PermissionError: [Errno 13] no Python. A aplicação tentou fazer uma coisa que o seu utilizador não pode. A resposta curta: numa conta partilhada, a aplicação corre com o mesmo utilizador da conta, por isso o erro quase nunca é «falta de permissão sobre os seus ficheiros», e quase sempre é uma de duas coisas: está a tentar escrever ou instalar fora da conta, ou a pasta tem o modo ou o dono errados depois de uma transferência.

O que a mensagem quer dizer

O que vê Causa habitual O que fazer
Erro ao escrever um ficheiro de dados ou de carregamentos A pasta não existe, ou não é sua, ou o caminho aponta para fora da conta (por exemplo /var ou /tmp/... fixo no código). Use uma pasta dentro da conta, criada por si, com um caminho relativo à aplicação.
sqlite3.OperationalError: unable to open database file ou «attempt to write a readonly database» O SQLite precisa de escrever no ficheiro e na pasta onde ele está (cria ficheiros temporários ao lado). Ponha a base de dados numa pasta onde a conta pode escrever. Para mais de um utilizador ao mesmo tempo, prefira MariaDB: ligar à base de dados a partir de Python e Node.js.
EACCES ao npm install Instalação global (-g) ou sudo. Instale dentro do ambiente da aplicação, sem -g. Veja erros do npm install.
EACCES ao ouvir numa porta A aplicação pede uma porta abaixo de 1024 (80, 443). Só o root pode. Não abra portas: aqui a aplicação é servida pelo domínio. Use process.env.PORT.
EPERM: operation not permitted Mudar o dono ou o modo de um ficheiro que não é seu (chown, chmod), ou apagar algo protegido. Só pode mudar o que é seu. Ficheiros enviados por outro utilizador ou restaurados de uma cópia podem ter o dono errado: abra um pedido.
403 Forbidden no browser, e não na aplicação Não é da aplicação: é o servidor web a recusar um ficheiro ou pasta. Erro 403: permissões, .htaccess e IPs bloqueados.

Os modos que costumam estar certos

1 Pastas com 755 e ficheiros com 644 são o habitual para o código. No Terminal: find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
Corra-o dentro da pasta da aplicação, e nunca na raiz da conta. Não toque na pasta node_modules nem no ambiente virtual: foram criados pela ferramenta.
2 O ficheiro de arranque (app.js, passenger_wsgi.py) tem de ser legível, não executável. Se o enviou por FTP, confirme o modo no cliente: o FileZilla e as permissões.
3 Pastas onde a aplicação escreve (carregamentos, ficheiros temporários, a base de dados SQLite) têm de ser do utilizador da conta e com escrita para o dono, o que o 755 já dá. Não precisa de mais.
4 Reinicie a aplicação e repita a acção que falhava.
Nunca resolva com chmod 777. Dá escrita a toda a gente, é a abertura preferida de quem ataca um site, e quase nunca é o que faltava. Se o 777 «resolveu», o problema real era o dono ou o caminho: descubra qual, em vez de deixar a porta aberta.
Veja o dono e o modo de um ficheiro com ls -l ficheiro e de uma pasta com ls -ld pasta. A primeira coluna é o modo; a terceira, o dono. Se o dono não for o utilizador da conta, é aí. Para o terminal: o Terminal do cPanel.

O dono ou o modo parecem errados e não os consegue mudar? Envie-nos o domínio e o caminho do ficheiro.

Abrir um pedido de suporte

VEJA TAMBÉM

npm install falha com EACCES, ERESOLVE ou falta de memória

Erro 403 Forbidden: permissões, .htaccess e IPs bloqueados

Ligar à base de dados a partir de Python e Node.js

PRODUTO RECOMENDADO

Alojamento de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 321,75 MT/mês (plano de 3 anos, com cupão)

Ver planos
  • 0 Utilizadores acharam útil
Esta resposta foi útil?