fwrite (w) warning

[xploit]

Boas, eu localmente tenho este script a funcionar correctamente, pus no meu servidor remoto, que usa UNIX, não funciona dá este erro:

Warning: fopen(../a/stopgame.now) [function.fopen]: failed to open stream: Permission denied in /home/yu/public_html/classes/class.WriteFile.php on line 14

Warning: fwrite(): supplied argument is not a valid stream resource in /home/yu/public_html/classes/class.WriteFile.php on line 15

Warning: fclose(): supplied argument is not a valid stream resource in /home/yu/public_html/classes/class.WriteFile.php on line 16

Agora não percebo é porquê...

Excerto de código da classe:

function  writer($FILENAME,$TEXT){
  $fp = fopen($this->Direction.$FILENAME, "w");
      $escreve = fwrite($fp, $TEXT);
      fclose($fp);						
}

tá em modo "W".. o que puderá ser?

[scorch]

Verifica se tens permissões para escrever ficheiros e se: "$this->Direction.$FILENAME" é um ficheiro que existe realmente. 😄

[xploit]

Não o ficheiro não existe, mas eu pensei que o fopen em modo W, cria-se o ficheiro caso ele não exista, certo?

[xploit]

E se for um problema de permissões onde altero? é na INI do php ou é permissão na pasta ou ficheiro especificamente?

[softklin]

É mesmo nas pastas/ficheiros. Se tiveres acesso SSH onde tens os ficheiros, basta aceder e fazer um chmod 755 (tu tens todas as permissões, o grupo e outros têm permissões de execução e leitura), ou outro valor que aches mais conveniente. Em alternativa, o teu cliente de FTP/painel do alojamento deve-te oferecer essas opções.

[xploit]

mas ele até para criar pastas com o mkdir("exe",755); diz que não tenho permissão para o fazer... não percebo eu acho que isto é alguma definição no php.ini não será? este tipo de situações é o que costuma acontecer nos HOST grátis, mas o meu é uma vps.. o que acham?

[softklin]

O PHP é explícito na mensagem: permission denied. Se o ficheiro fosse remoto, ainda se podia considerar o facto de teres a função de obter ficheiros remotos inactiva, mas como se tratam de ficheiros locais, é quase de certeza problema de permissões.

Se o teu host é um VPS, então provavelmente tens acesso à consola. Na consola, vais à pasta dos ficheiros web e espreita as permissões, listando os ficheiros:

ls -l

Como não sei ao certo como aparece a listagem, visto que não sou utilizador assíduo de Linux, deixo-te aqui uns links da wiki para te ajudar a determinar as permissões necessárias:

http://wiki.portugal-a-programar.pt/sistemas_operativos:linux:tutorial_chmod

[xploit]

mas essas permissões dá para dar com o próprio filezilla por exemplo.. eu ja experimentei dar permissão 755 ao root  a pasta que contém todos os files e está na mesma, penso que não seja necessário fazer-lo por ssh...

[softklin]

Sim, o Filezilla tem essa opção, embora não a tenha usado, deveria funcionar. Se pesquisares no Google, verificas que se trata quase sempre, senão sempre, de permissões. Tenta verificar com SSH se o Filezilla está efectivamente a escrever as permissões.

Mas espera lá, estás a abrir o ficheiro para escrita? Experimenta usar o modo 766, que te permite que outros (provavelmente onde está o PHP) tenham permissões de escrita e leitura. Em último caso, tenta 777.

[yoda]

Essa função no Filezilla funciona perfeitamente, exceptuando uma situação (e neste caso o problema não é do filezilla) : se a conta ftp não for a mesma do criador do ficheiro, este não tem permissões para mudar isso.

[xploit]

fui verificar no próprio ftp do cpanel, e ele diz que todos os ficheiros o root inteiro está a 755, portanto não estou a perceber o que se está a passar, os caminhos estão fora de questão porque estão certissimos, eu na minha antiga vps o sistema funcionava perfeitamente, mudei para esta nova e aconteceu me isto, leva me a entender que é uma outra configuração para além das permissões as pastas e ficheiros, será que pode ser alguma configuração no apache ou assim?

realmente não percebo...

Obrigado pelas vossas indispensáveis ajudas  😄

[softklin]

Não sei se reparaste na minha última resposta, mas eu indiquei-te para colocar as permissões a 766 (escrita e leitura), em vez dos 755 (leitura e execução, sem escrita (w)). Pode ser disso, visto que estás a escrever em ficheiros e com 755 não tens permissões de escrita (grupo e outros, ode estará o PHP possivelmente).

[xploit]

Vou testar então ja aqui ponho o resultado.

Obrigado softclean

[xploit]

Só funciona com permissão 777, a 766 inibe o resultado para o público, mas a 777 a minha aplicação fica inseguro não é?

[softklin]

Sim, porque estás a dar permissões totais (escrita, leitura e execução) para toda a gente, mas não sei se fará diferença num ambiente web. Eu não costumo mexer muito em Linux como disse, por isso será melhor aguardar a resposta de alguém que te saiba recomendar melhor as permissões que deves aplicar nesse caso.

[xploit]

Problema resolvido, a experimentar cheguei lá, mudei o PHP HANDLER da VPS para o modo "cgi" tava em modo "dso", alguém me sabe explicar porquê que o modo dso atrufia-se com as permissões? já agora gostava de saber o porquê de ter que ser assim...

Obrigado a todos.

[jreis]

Geralmente tem a ver com o utilizador em que o PHP corre, depende um pouco da distribuição usada/configuração, mas a partida em modo DSO/module o php é executado pelo Apache (e respectivo utilizador), já em CGI costuma ser o "nobody" (ou será o inverso??). Sem poder alterar o dono e/ou grupo das pastas, a única opção é mesmo usar permissões 777 na pasta.