Configurando o Diretório Temporário

Recentemente, mudei um site de um host local para um VPS. Eu consegui tornar os arquivos públicos e privados graváveis; no entanto, não sei onde encontrar a pasta temporária e como alterar as permissões. Eu continuo recebendo esta mensagem:

O arquivo especificado temporary: // file3Hl91E não pôde ser copiado, porque o diretório de destino não está configurado corretamente. Isso pode ser causado por um problema com as permissões de arquivo ou diretório. Mais informações estão disponíveis no log do sistema.

Estou usando o Virtualmin, Drupal 7 e um servidor Debian. Meu diretório temporário atual é /tmp.

Marque Administrador -> Configuração -> Mídia -> Sistema de arquivos para personalizar seu caminho tmp. Certifique-se de usar caminhos relativos e ter os privilégios corretos para o usuário do Apache.

Pessoalmente, gosto deste artigo, corrigi o upload de arquivos . Ele tem boas observações. Funcionou para mim.

Recentemente, baixei meu site para o meu computador Mac. Acontece que no meu Mac eu estava usando o mod_userdirApache e esqueci que /etc/apache2/users/nameofuser.confpreciso definir AllowOverride All, caso contrário, terei a seguinte mensagem:

O arquivo temporário especificado não pôde ser copiado porque o diretório de destino não está configurado corretamente.

Em seu settings.php

$conf['file_temporary_path'] = '/tmp';

Isso funcionará em sistemas unix 99% do tempo.

Geralmente, o diretório / tmp existe em sistemas UNIX com permissões abertas, e existe especificamente para arquivos temporários e geralmente é configurado para melhorar o desempenho.

Você pode verificar as permissões executando ls -al /tmpna linha de comando.

Se você estiver interessado em ler mais sobre isso, consulte https://en.wikipedia.org/wiki/Temporary_folder

É importante entender que um problema de permissão pode existir no SEU diretório temporário especificado (definido em admin / config / media / sistema de arquivos) E na pasta em que esse arquivo temporário será copiado. Eu já vi esse erro algumas vezes e geralmente não é um problema com a pasta temporária, mas com a pasta final em que esse arquivo é copiado depois de viver na pasta temporária.

Verifique também se o caminho do sistema de arquivos público está definido corretamente.

Eu tive esse problema exato e certifique-se de usar o caminho relativo (sites / default / files / tmp) para o local da minha pasta tmp, conforme sugerido, e também alterei as permissões na pasta tmp para garantir que fosse gravável pelo apache, mas meu problema ainda existia . por isso, decidi verificar as mensagens de log (Relatórios >> Mensagens recentes de log) para ver se conseguia entender melhor qual era o problema. Ao fazer isso, recebi uma mensagem mais específica:

As permissões do arquivo não puderam ser definidas em public: // js.

Isso me levou a verificar as permissões na pasta js em sites / default / files e, como se vê, o apache não pôde gravar nele, alterando as permissões para 775 nessa pasta, me livrei da minha mensagem de erro. Então, eu sugiro que você verifique as permissões para todas as subpastas em sites / default / files e não apenas a pasta tmp, se você ainda não resolveu o seu problema. Apenas pensei em compartilhar essa informação.

você pode encontrar as configurações do sistema de arquivos em admin/config/media/file-system / tmp

também você pode verificar admin / reports / status para qualquer problema de configuração

sobre a permissão / tmp, você pode conceder 755 e encontrará em / public_html

Às vezes, a mensagem de erro pode ser enganosa

Se ele diz que o problema está relacionado ao diretório de destino, o apache provavelmente não tem permissão para gravar na subpasta sites / default / files que o Drupal deseja colocar no arquivo.

Uma boa solução é tornar o usuário apache o proprietário de todos os arquivos e diretórios em sites / default / files

cd /path/to/sites/default
sudo chown -R _www:_www files

Ou algo semelhante deve resolver os problemas do diretório de destino. Verifique se o proprietário possui permissões de gravação e execução em todos os subdiretórios.

O diretório de arquivos: Solucionando problemas de servidores Web baseados em Apache

Se os arquivos de diretório não pertencerem ao servidor Web, há duas maneiras de prosseguir. Essas instruções pressupõem que você tenha acesso de shell ao servidor da Web. Se você não tiver acesso ao shell, entre em contato com seu provedor de hospedagem para obter suporte adicional.

Idealmente, você poderá alterar o "proprietário" dos arquivos de diretório para corresponder ao nome do servidor da Web. Em um servidor baseado em Unix ou Linux, você pode verificar "quem" o servidor da Web está executando, emitindo os seguintes comandos:

$ ps aux  |grep apache # for Apache 2.x
$ ps aux  |grep httpd # for Apache 1.x

Dependendo do servidor da Web, um desses comandos retornará uma série de linhas como esta:

www-data 13612  0.1  0.9  50640 20340 ? S 12:29   0:08 /usr/sbin/apache2 -k start

A primeira coluna no texto retornado é o "usuário" em que o servidor da Web está operando. Nesse caso, o usuário é www-data. Para tornar seu diretório de arquivos gravável pelo servidor da Web, você precisa reatribuir sua propriedade usando o seguinte comando:

$ chown -R www-data sites/default/files
$ chmod -R 0700 sites/default/files

Se você não tiver permissões suficientes no servidor para alterar a propriedade da pasta, a próxima melhor opção é fornecer acesso de gravação em grupo à pasta com o seguinte comando:

$ chmod -R 0770 sites/default/files

Você também deve poder ajustar as permissões do diretório usando um programa FTP, conforme descrito acima.

Depois de concluir essas etapas, confirme se as permissões apropriadas foram atribuídas navegando para Administrar -> Relatórios -> Relatório de status. Vá até a seção "Sistema de arquivos" e confirme se suas configurações estão corretas.

Fonte: O diretório de arquivos

Outra fonte de erro é que ele não pode gravar na pasta de arquivos. No meu caso, resolvi usando:

$chmod 777 sites/default/files/pictures/

Em algumas situações, isso pode ser facilmente corrigido excluindo as pastas 'ctools' e 'js' nos arquivos / padrão. Essas pastas são recriadas pelo sistema, se necessário. Às vezes, ao fazer uma nova instalação de um site existente, essas pastas já causam problemas. Além disso, se o seu CSS não estiver funcionando depois de fazer uma nova instalação de um site existente, isso também poderá ser corrigido excluindo esses arquivos e permitindo que o drupal os recrie.

Minha configuração antiga e problemática

chmod 664 -R /var/drupal-bc/sites/default/files
chmod 664 -R /var/drupal-bc/sites/default/private

drw-rw-r-- 2 www-data www-data  4096 Jul 31 12:35 files
drw-rw-r-- 3 www-data www-data  4096 Jul  5 15:08 private

Minha nova e boa configuração

chmod 774 -R /var/drupal-bc/sites/default/files
chmod 774 -R /var/drupal-bc/sites/default/private

drwxrwxr-- 2 www-data www-data  4096 Jul 31 12:35 files
drwxrwxr-- 3 www-data www-data  4096 Jul  5 15:08 private

As permissões corretas para a pasta temporária dependem da configuração do servidor da web.

Se você estiver executando o Drupal com PHP como módulo de servidor da web, por exemplo, Apache, quando o usuário definido no arquivo de configuração principal do servidor da web usando a diretiva Usuário deverá ter acesso a ele.

% grep -i "usuário" /etc/httpd/conf/httpd.conf

Usuário apache

Eu tive esse mesmo problema depois de passar de um servidor para outro.

Tentei tudo o que foi sugerido aqui, definindo pastas para 755 e assim por diante.

Minha pasta temporária foi definida como "" tmp7zXhVVCO "e, na verdade, copiou bem os arquivos de instalação, depois de cada nova tentativa, o arquivo temporário era copiado para lá, mas a instalação continuava falhando.

O problema, no entanto, é o proprietário, não os direitos, e é por isso que o 777 remove esse erro, mas todos sabemos que esse não é um caminho a percorrer nos locais de produção.

O que você deve fazer é alterar sua pasta temporária para qualquer outra coisa, como "temp" ou o que mais lhe convier, desde que ainda não exista , o drupal criará essa nova pasta com direitos apache , não direitos do usuário e seu problema será resolvido.

Eu realmente não gosto de nenhuma das respostas existentes, então vou começar uma que eu provavelmente atualizarei com o tempo. Principalmente com comandos de shell.

Por enquanto, execute isso em sites/example.com:

MYSITE=example.com
FILES=sites/$MYSITE/files  
# CSS and JS might also cause trouble and advagg has its own dirs
TMPDIRS=$FILES/tmp $FILES/js $FILES/css $FILES/advagg_*
drush vset file_temporary_path $FILES/tmp # seems better than using /tmp
drush vset file_directory_temp $FILES/tmp
cd $(drush drupal-directory)   
chown www-data -R $TMPDIRS
chmod 755 -R $TMPDIRS

Em Configuração -> Mídia -> Sistema de arquivos, removi o / temp-catalog. Depois disso, não tive mais problemas.

Eu tive o mesmo problema em uma migração. Eu tenho chmod 777 todos os sites / padrão / arquivos, mas o erro ainda acontece. Altero a permissão 775 em sites / padrão / arquivos e a mensagem desapareceu. Eu não era um problema de caminho privado, o meu é / var / tmp, mas a permissão 775.

Se você se deparar com esse problema usando o Pantheon e continuar recebendo o erro após definir o (s) caminho (s) do diretório de arquivos (temp), também poderá ser necessário alternar o modo de conexão no painel da instância de desenvolvimento do Git para SFTP.

Seu site Drupal pode estar tentando salvar arquivos em um diretório gerenciado pelo Git (por exemplo, se você estiver alterando as configurações de layout e similares em um tema de Temas Adaptativos). Para fazer isso, mude para SFTP. Depois que os arquivos forem salvos, você poderá voltar para o Git, e o painel solicitará que você confirme as alterações feitas no servidor.

Eu tive o mesmo problema.

Eu estava usando o IIS no Windows. Finalmente, o problema estava nas permissões nos sites de pastas / default / files e, obviamente, nos sites / default / files / tmp.

Finalmente, dei novamente "Permissões totais" para as pastas, e funcionou.

Saudações