Log diário do Laravel criado com permissões erradas

112

Eu tenho um script que executo usando php artisan (com usuário root ), e às vezes faz com que o arquivo de log diário seja criado antes do usuário www-data do apache - o que significa que quando um usuário real usa meu aplicativo da web, eu obtenho o erro de permissão de pasta:

Falha ao abrir o stream: permissão negada

Eu mudo as permissões de volta para www-data todas as vezes, mas quero resolver isso tendo o arquivo de log sempre criado com as permissões corretas.

Pensei em criar um cron job que cria o arquivo ou o toca para ter certeza de que tem a permissão certa todos os dias, mas estou procurando uma solução melhor que não dependa de outro script.

Também consideramos envolver o php artisan em outro script para ter certeza de que ele sempre será executado com as credenciais www-data , mas algumas coisas que queremos fazer são, na verdade, procedimentos de root que o apache não deve ter permissão para fazer.

Mais alguma sugestão?

NiRR
fonte
Configure um crontrabalho para touchum novo arquivo de log à meia-noite todos os dias (com o usuário correto, é claro).
Ben Harold
@BenHarold Obrigado, nós consideramos isso, mas prefiro não envolver mais scripts.
NiRR
2
Nesse caso, você precisará executar php artisancomo o usuário que deseja criar o arquivo de log.
Ben Harold
@BenHarold Mais uma vez, obrigado, nós também consideramos isso, que provavelmente é a melhor maneira de fazer, mas eu atualizei a pergunta para explicar por que isso também não é o ideal.
NiRR
2
O que funcionou para mim foi executar o cron como o usuário www-data comsudo crontab -u www-data -e
Nil Llisterri

Respostas:

67

Vamos começar com o que é constante.

Você tem um php artisancomando, executado por root.

É seguro presumir que esse comando seja executado diariamente.

Solução Nº 1:

Dado que o usuário que cria os arquivos é aquele que tem permissão para gravar neles por padrão, podemos separar os registros por usuário da seguinte forma:

App/start/global.php

/*
|--------------------------------------------------------------------------
| Application Error Logger
|--------------------------------------------------------------------------
|
| Here we will configure the error logger setup for the application which
| is built on top of the wonderful Monolog library. By default we will
| build a basic log file setup which creates a single file for logs.
|
*/

Log::useDailyFiles(storage_path().'/logs/laravel-'.get_current_user().'.log');

Se o seu www-data usuário foram para criar um log de erro, isso resultaria em: storage/logs/laravel-www-data-2015-4-27.log.

Se a sua raiz usuário fosse para criar um log de erro, isso resultaria em: storage/logs/laravel-root-2015-4-27.log.

Solução No 2:

Mude o log usado pelo seu comando artisan, em seu script php.

Em sua run()função, adicione esta linha no início:

Log::useFiles(storage_path().'/logs/laravel-'.__CLASS__.'-'.Carbon::now()->format('Y-m-d').'.log');

Se o nome da sua turma for ArtisanRunner, seu arquivo de registro será:

storage/logs/laravel-ArtisanRunner-2015-4-27.log.

Conclusão: a solução número 1 é melhor, pois delineia seus logs por usuário e, portanto, nenhum erro ocorrerá.

EDIT: conforme apontado por jason, get_current_user()retorna o nome do proprietário do script. Portanto, para a solução nº 1 ser aplicada, chownseus arquivos de classe de artesão para o nome de usuário necessário.

Mysteryos
fonte
12
Observe que get_current_user()retorna o proprietário do script PHP atual (de acordo com php.net) e não o usuário que está executando o script no momento. Eu uso php_sapi_name(), em vez disso, que fornece o nome do manipulador de php (apache ou cli, por exemplo), que tende a ser executado como usuários diferentes.
Jason
1
Posso fazer a sugestão de usar o nome de usuário executando o script e php_sapi_name em combinação, já que é possível para muitos usuários executar o Laravel a partir da CLI, por exemplo, alguns DBAs acessam seu servidor ou você pode querer que o Laravel CRON rode como apache. Você pode obtenha o nome do processo executando este script usando posix_getpwuid (posix_geteuid ()) ['nome']; Veja minha postagem completa abaixo.
Andrew
Precisa ser atualizado para as últimas versões do Laravel: v5 +
Andrew
105

Laravel versão 5.6.10 e posterior tem suporte para um permissionelemento na configuração ( config/logging.php) para o singlee o dailydriver:

    'daily' => [
        'driver' => 'daily',
        'path' => storage_path('logs/laravel.log'),
        'level' => 'debug',
        'days' => 7,
        'permission' => 0664,
    ],

Não há necessidade de fazer malabarismos com o Monolog no script de bootstrap.

Especificamente, o suporte foi adicionado em https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8 .

Crishoj
fonte
8
isso deve estar no documento oficial!
odupont
3
apóstrofos estão faltando nesta resposta. Deve ser 'permission' => '0664'. Então essa resposta está perfeitamente correta!
Phil
2
@Phil Nope - este é apenas um invólucro para o manipulador de fluxo Monologs que aceita um int para permissões. Monolog envolve php.net/manual/en/function.chmod.php - observe que um 0 à esquerda é necessário para garantir que seja um valor octal
Chris
7
'permission' => 0664funciona para mim (sem aspas)
Syclone
2
@Friedrich se o seu arquivo de registro está sendo criado com 'root' como o proprietário do arquivo, isso provavelmente indica que você tem problemas maiores em termos de como o seu servidor da web está configurado
kjones
62

Para o Laravel 5.1, uso o seguinte na parte inferior bootstrap/app.php(conforme mencionado na documentação ):

/**
 * Configure Monolog.
 */
$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('logs/laravel-'.php_sapi_name().'.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename);
    $monolog->pushHandler($handler);
});

Existem muitos outros manipuladores que você pode usar em vez disso, é claro.

Sam Wilson
fonte
1
Eu realmente gosto desta resposta porque 1) ela foi atualizada para 5.1 e 2) usa um método na documentação para estender o comportamento do log.
Dylan Pierce
Excelente, o forward-flash extra não é necessário, mas ainda funciona. Ele deve ser ... $ filename = storage_path ('logs / laravel -'. Php_sapi_name (). '. Log');
Andrew
Posso fazer a sugestão de usar o nome de usuário executando o script e php_sapi_name em combinação, já que é possível para muitos usuários executar o Laravel a partir da CLI, por exemplo, alguns DBAs acessam seu servidor ou você pode querer que o Laravel CRON rode como apache. Você pode obtenha o nome do processo executando este script usando posix_getpwuid (posix_geteuid ()) ['nome']; Veja minha postagem completa abaixo.
Andrew
1
Como usar no Laravel 5.6? Porque o Laravel 5.6 tem um novo sistema de Logging.
Hamed Kamrava
26

Para tais propósitos, você deve usar ACL avançado em seus arquivos e diretórios. setfaclseria sua resposta aqui. Se você quiser dar ao usuário www-data permissões para gravar nos arquivos do root em um diretório específico, você pode fazer assim:

setfacl -d -m default:www-data:you-chosen-group:rwx /my/folder

Após a emissão do presente você está definindo permissões para rwxpara www-data usuário em todos os arquivos /my/folder/, não importa o que criou aqueles. Por favor, veja esta e esta pergunta para referência. Além disso, você pode verificar os documentos parasetfacl .

Avise-me se isso ajudar.

Paweł Tomkiel
fonte
3
O seguinte comando funcionou para mim: setfacl -d -m g:www-data:rw /full/path/to/laravel/storage/logsseguido por php artisan cache:cleare composer dump-autoload.
Sawny
17

Eu fiz isso funcionar de maneira muito simples:

Encontrei o mesmo problema no Laravel 5.6

Em config/logging.phpI acaba de atualizar valor de caminho de canal diário com php_sapi_name()nela.

Isso cria um diretório separado para diferentes php_sapi_name e coloca o arquivo de log com o carimbo de data / hora em seu diretório perticular.

'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ]

Então, para mim,

  • Os arquivos de log são criados no fpm-fcgidiretório: Logs do site,owner: www-data
  • Os arquivos de log são criados no clidiretório: a partir do comando artisan (cronjob).owner: root

Mais informações sobre o registro do Laravel 5.6: https://laravel.com/docs/5.6/logging

Aqui está meu config/logging.phparquivo:

<?php

return [
    /*
    |--------------------------------------------------------------------------
    | Default Log Channel
    |--------------------------------------------------------------------------
    |
    | This option defines the default log channel that gets used when writing
    | messages to the logs. The name specified in this option should match
    | one of the channels defined in the "channels" configuration array.
    |
    */
    'default' => env('LOG_CHANNEL', 'stack'),
    /*
    |--------------------------------------------------------------------------
    | Log Channels
    |--------------------------------------------------------------------------
    |
    | Here you may configure the log channels for your application. Out of
    | the box, Laravel uses the Monolog PHP logging library. This gives
    | you a variety of powerful log handlers / formatters to utilize.
    |
    | Available Drivers: "single", "daily", "slack", "syslog",
    |                    "errorlog", "custom", "stack"
    |
    */
    'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['daily'],
        ],
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ],
        'slack' => [
            'driver' => 'slack',
            'url' => env('LOG_SLACK_WEBHOOK_URL'),
            'username' => 'Laravel Log',
            'level' => 'critical',
        ],
        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],
        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],
    ],
];
Lahar Shah
fonte
legal ... sua solução é mais limpa .. estou testando agora
Sina Miandashti
1
Como foi apontado em outro comentário, os logs são apenas uma parte da história. Existem visualizações compiladas, caches de dados, código-fonte pré-armazenado em cache, qualquer um dos quais pode ser criado como arquivo local pela web ou pelo usuário cli.
Jason
2
Isso não funciona se você armazenar em cache a configuração usando artisan config:cache, uma vez que criará um cache de configuração usando o cli SAPI que será usado para solicitações CLI e web.
leeb de
1
Isso funciona para mim, tentei get_current_usernão funciona, mas php_sapi_namefunciona (embora pareça mais feio)
Richard Fu
Acho que essa é a melhor e mais rápida maneira. Modificar a configuração não altera a estrutura básica do Laravel, apenas a configuração.
William Prigol Lopes
12

Para mim, esse problema era muito mais do que permissões de registro ... Tive problemas com qualquer coisa relacionada ao bootstrap / cache e pastas de armazenamento onde um usuário criava um arquivo / pasta e o outro não conseguia editar / excluir devido ao padrão 644 e 755 permissões.

Os cenários típicos são:

  • O arquivo bootstrap / cache / compiled.php sendo criado pelo usuário apache, mas não pode ser editado pelo usuário composer ao executar o comando de instalação do composer

  • O usuário apache criando o cache que não pode ser limpo usando o usuário composer

  • As temidas condições de corrida de toras descritas acima.

O sonho é que não importa qual usuário crie o arquivo / pasta, os outros usuários que precisam acessar têm exatamente as mesmas permissões do autor original.

TL; DR?

Veja como isso é feito.

Precisamos criar um grupo de usuários compartilhado chamado laravel, o grupo consiste em todos os usuários que precisam de acesso aos diretórios de armazenamento e bootstrap / cache. Em seguida, precisamos garantir que os arquivos e pastas recém-criados tenham o grupo laravel e as permissões 664 e 775, respectivamente.

É fácil fazer isso para arquivos / diretórios existentes, mas um pouco de mágica é necessária para ajustar as regras de criação de arquivos / pastas padrão ...

## create user group
sudo groupadd laravel

## add composer user to group
sudo gpasswd -a composer-user laravel

## add web server to group
sudo gpasswd -a apache laravel

## jump to laravel path
sudo cd /path/to/your/beautiful/laravel-application

## optional: temporary disable any daemons that may read/write files/folders
## For example Apache & Queues

## optional: if you've been playing around with permissions
## consider resetting all files and directories to the default
sudo find ./ -type d -exec chmod 755 {} \;
sudo find ./ -type f -exec chmod 644 {} \;

## give users part of the laravel group the standard RW and RWX
## permissions for the existing files and folders respectively
sudo chown -R :laravel ./storage
sudo chown -R :laravel ./bootstrap/cache
sudo find ./storage -type d -exec chmod 775 {} \;
sudo find ./bootstrap/cache -type d -exec chmod 775 {} \;
sudo find ./storage -type f -exec chmod 664 {} \;
sudo find ./bootstrap/cache -type f -exec chmod 664 {} \;


## give the newly created files/directories the group of the parent directory 
## e.g. the laravel group
sudo find ./bootstrap/cache -type d -exec chmod g+s {} \;
sudo find ./storage -type d -exec chmod g+s {} \;

## let newly created files/directories inherit the default owner 
## permissions up to maximum permission of rwx e.g. new files get 664, 
## folders get 775
sudo setfacl -R -d -m g::rwx ./storage
sudo setfacl -R -d -m g::rwx ./bootstrap/cache

## Reboot so group file permissions refresh (required on Debian and Centos)
sudo shutdown now -r

## optional: enable any daemons we disabled like Apache & Queues

Puramente para fins de depuração, descobri que dividir os logs em ambos os usuários cli / web + foi benéfico, então modifiquei um pouco a resposta de Sam Wilson. Meu caso de uso foi a fila executada sob seu próprio usuário, então ajudou a distinguir entre o usuário do compositor usando o cli (por exemplo, testes de unidade) e o daemon de fila.

$app->configureMonologUsing(function(MonologLogger $monolog) {
     $processUser = posix_getpwuid(posix_geteuid());
     $processName= $processUser['name'];

     $filename = storage_path('logs/laravel-'.php_sapi_name().'-'.$processName.'.log');
     $handler = new MonologHandlerRotatingFileHandler($filename);
     $monolog->pushHandler($handler);
}); 
Andrew
fonte
Isso é muito bom. configureMonologUsingPorém, seu código ainda é necessário, depois de executar os setfaclcomandos?
jeff-h
7

Laravel 5.1

Em nosso caso, queríamos criar todos os arquivos de log de forma que tudo no deploygrupo tivesse permissão de leitura / gravação. Portanto, precisamos criar todos os novos arquivos com 0664permissões, ao contrário do 0644padrão.

Também adicionamos um formatador para adicionar novas linhas para melhor legibilidade:

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});

Também é possível combinar isso com a resposta aceita

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel-' . php_sapi_name() . '.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});
Artur Käpp
fonte
6

Uma maneira não-Laravel de fazer isso funcionar é simplesmente executar seu cronjob como dados www.

por exemplo, /ubuntu/189189/how-to-run-crontab-as-userwww-data

/etc/crontab

*/5 * * * * www-data php /var/www/public/voto_m/artisan top >/dev/null 2>&1

user2662680
fonte
5

Laravel 5.5

Adicione este código a bootstrap/app.php:

$app->configureMonologUsing(function (Monolog\Logger $monolog) {
    $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
    $monolog->pushHandler($handler = new Monolog\Handler\RotatingFileHandler($filename, 30));
    $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
    $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
    $formatter->includeStacktraces();
    $handler->setFormatter($formatter);
});
  • Ele armazenará arquivos como este: laravel-2018-01-27-cli-raph.logelaravel-2018-01-27-fpm-cgi-raph.log que são mais legíveis.
  • Novas linhas são preservadas (como comportamento padrão do Laravel)
  • Funciona com o Laravel Log Viewer

Laravel 5.6

Você deve criar uma classe para o seu logger:

<?php

namespace App;

use Monolog\Logger as MonologLogger;

class Logger {
    public function __invoke(array $config)
    {
        $monolog = new MonologLogger('my-logger');
        $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
        $monolog->pushHandler($handler = new \Monolog\Handler\RotatingFileHandler($filename, 30));
        $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
        $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
        $formatter->includeStacktraces();
        $handler->setFormatter($formatter);
        return $monolog;
    }
}

Então, você deve registrá-lo em config/logging.php:

'channels' => [
    'custom' => [
        'driver' => 'custom',
        'via' => App\Logging\CreateCustomLogger::class,
    ],
],

Mesmo comportamento do 5.5:

  • Ele armazenará arquivos como este: laravel-2018-01-27-cli-raph.logelaravel-2018-01-27-fpm-cgi-raph.log que são mais legíveis.
  • Novas linhas são preservadas (como comportamento padrão do Laravel)
  • Funciona com o Laravel Log Viewer
rap-2-h
fonte
Melhor resposta! Kudos
Shahid Karimi
4

Adicione algo como o seguinte no início do seu app/start/artisan.phparquivo (isto é com o Laravel 4):

// If effectively root, touch the log file and make sure it belongs to www-data
if (posix_geteuid() === 0) {
    $file = storage_path() . '/logs/laravel.log';
    touch($file);
    chown($file, 'www-data');
    chgrp($file, 'www-data');
    chmod($file, 0664);
}

Ajuste o caminho se o arquivo de log diário que você mencionou não for o arquivo de log padrão do Laravel. Você também pode não querer alterar o grupo ou definir as permissões como estou fazendo aqui. O item acima define o grupo como www-datae as permissões de gravação do grupo. Em seguida, adicionei meu usuário regular ao www-datagrupo para que a execução de comandos artisan como meu usuário regular ainda possa gravar no log.

Um ajuste relacionado é colocar o seguinte no início de seu app/start/global.phparquivo:

umask(0002);

Se você fizer isso, a chmodlinha acima se tornará discutível. Com o umask definido para isso, quaisquer novos arquivos que o PHP (e, portanto, o Laravel) criar terão suas permissões mascaradas apenas para que "outros" usuários não tenham permissão de gravação. Isso significa que os diretórios começarão como rwxrwxr-xe os arquivos como rw-rw-r--. Portanto, se www-dataestiver executando o PHP, qualquer cache e arquivos de log que ele criar serão graváveis ​​por padrão por qualquer pessoa do grupo principal do usuário, que é www-data.

trêmulo
fonte
4

(Laravel 5.6) Recentemente, encontrei o mesmo problema e simplesmente configurei um comando agendado para ser executado /app/Console/Kernel.php.

$schedule->exec('chown -R www-data:www-data /var/www/**********/storage/logs')->everyMinute();

Eu sei que é um pouco exagerado, mas funciona perfeitamente e não teve nenhum problema desde então.

Ague Mort
fonte
Funciona ? Sim, mas é a melhor prática? Eu acho que não.
Pablo Papalardo
3

Laravel 5.4

\Log::getMonolog()->popHandler(); \Log::useDailyFiles(storage_path('/logs/laravel-').get_current_user().'.log');

adicionar para bootfuncionar emAppServiceProvider

StupidDev
fonte
1

Laravel 5.8

Laravel 5.8 permite que você defina o nome do log em config/logging.php .

Então, usando respostas e comentários anteriores, se você quiser nomear seu log usando o nome de usuário posix real E o php_sapi_name() valor, você só precisa alterar o conjunto de nomes de log. Usar o driver diário permite a rotação do log que é executada por combinação de usuário / API, o que garantirá que o log seja sempre girado por uma conta que pode modificar os logs.

Eu também adicionei uma verificação para as funções posix que podem não existir em seu ambiente local, caso em que o nome do log apenas assume o padrão.

Supondo que você esteja usando o canal de registro padrão 'diário', você pode modificar sua chave de 'canais' assim:

# config/logging.php
'channels' => [
    ...
    'daily' => [
        'driver' => 'daily',
        'path'   => storage_path(
            function_exists('posix_getpwuid') 
            && function_exists('posix_geteuid')
                ? 'logs/laravel'
                    . '-' . php_sapi_name()
                    . '-' . posix_getpwuid(posix_geteuid())['name'] 
                    . '.log'
                : 'logs/laravel.log'),
        'level'  => 'debug',
        'days'   => 15,
    ],
    ...

Isso resultará em um nome de registro que deve ser exclusivo para cada combinação, como laravel-cli-sfscs-2019-05-15.logou laravel-apache2handler-apache-2019-05-15.logdependendo do seu ponto de acesso.

sfscs
fonte
0

Você pode simplesmente alterar a permissão do arquivo de log em seu comando artisan:

$path = storage_path('log/daily.log');
chown($path, get_current_user());

onde get_current_user () retornará o usuário do script atual.

Em outras palavras, daily.logsempre terá www-datacomo seu dono, mesmo que inicialize o script como rootusuário.

Adão
fonte
0

Se você estiver usando o Laravel Envoyer , aqui está uma possível correção usando ACL no Linux:

1. Primeiro, execute o seguinte script com rootpermissões no servidor:

Em ambos os scripts, você precisará substituir as variáveis ​​conforme as instruções abaixo:

  • {{MASTER_PATH}} : O caminho para o diretório de seus hosts virtuais (por exemplo, a pasta> que contém seus aplicativos).
  • {{WEB_SERVER_USER}} : O usuário que seu servidor da web usa.
  • {{DEPLOYMENT_USER}} : O usuário pelo qual seu script de implantação é executado.
#!/bin/bash

DIRS="storage current/bootstrap/cache"
MASTER_PATH={{MASTER_PATH}}

if [ -d $MASTER_PATH ]; then 
    cd $MASTER_PATH
    for p in `ls $MASTER_PATH`; do 
        if [ -d $MASTER_PATH/$p ]; then     
        cd $MASTER_PATH/$p
            echo "Project: $p -> $MASTER_PATH/$p"
            for i in $DIRS; do 
                echo "- directory: $i" 
                if [ -d $i ]; then 
                    echo "-- checking ACL..."
                    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
                    if [  $HAS_ACL -eq 0 ]; then 
                        echo "--- applying $i"
                        setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                        setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                    else
                        echo "--- skipping $i"
                    fi
                fi
            done
        echo "--------------"
        fi
    done
else
    echo "No $MASTER_PATH - skipping overall"
fi

2. Configure o seguinte gancho de implantação no envoyer em "Ativar nova versão"> "Antes desta ação

PROJECT_DIRS="storage"
RELEASE_DIRS="bootstrap/cache"
 
cd {{ project }}
 
for i in $PROJECT_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done
 
cd {{ release }}
 
for i in $RELEASE_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done

3. Reimplante seu aplicativo

Agora, reimplante seu aplicativo e ele deve funcionar no futuro.

Nota: O script definido em 1. deve ser executado toda vez que você adiciona um novo projeto à máquina.

Emil Pedersen
fonte
0
cd /path/to/project
chown -R www-data:root .
chmod -R g+s .
Eduardo
fonte
-1

A melhor maneira que encontrei é que a sugestão do fideloper, http://fideloper.com/laravel-log-file-name , você pode definir a configuração do log laravel sem tocar na classe Log. Ter nomes diferentes para programas de console e programas Http, eu acho, é a melhor solução.

Giacomo
fonte
-1

Esta solução definitivamente funcionará no Laravel V5.1 - V6.x

Razões para este erro:

  • Principalmente devido a problemas de permissão
  • Variáveis ​​de ambiente não encontradas ou .envarquivo não encontrado em seu diretório raiz
  • Problema de extensões PHP
  • Problema de banco de dados

Consertar:

  • Defina as permissões corretas:
    • Execute esses comandos (Ubuntu / Debian)
find /path/to/your/root/dir/ -type f -exec chmod 644 {} \;
find /path/to/your/root/dir/ -type d -exec chmod 755 {} \;

chown -R www-data:www-data /path/to/your/root/dir/

chgrp -R www-data storage bootstrap/cache
chmod -R ug+rwx storage bootstrap/cache
  • Se o arquivo .env não existir, crie um por touch .enve cole suas variáveis ​​de ambiente e execute
   php artisan key:generate
   php artisan cache:clear
   php artisan config:clear
   composer dump-autoload
   php artisan migrate //only if not already migrated
Smit Patel
fonte