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?

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.

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 .

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.

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.

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',
        ],
    ],
];

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);
}); 

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);
});

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

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

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.

(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.

Laravel 5.4

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

adicionar para bootfuncionar emAppServiceProvider

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.

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.

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.

cd /path/to/project
chown -R www-data:root .
chmod -R g+s .

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.

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