Tengo un script que ejecuto usando php artisan (con usuario root ) y, a veces, hace que el archivo de registro diario se cree antes de que lo haga el usuario de www-data de Apache , lo que significa que cuando un usuario real usa mi aplicación web, obtengo el error de permiso de carpeta:

Error al abrir la transmisión: permiso denegado

Cambio los permisos de nuevo a www-data cada vez, pero quiero resolver esto haciendo que el archivo de registro siempre se cree con los permisos correctos.

He considerado crear un trabajo cron que cree el archivo o lo toque para asegurarme de que tenga el permiso correcto todos los días, pero estoy buscando una solución mejor que no dependa de otro script.

También hemos considerado envolver php artisan en otro script para asegurarnos de que siempre se ejecute con las credenciales de www-data , pero algunas cosas que queremos hacer son en realidad root procedimientos de que apache no debería poder hacer.

¿Alguna sugerencia más?

Empecemos por lo constante.

Tienes un php artisancomando, corre root.

Es seguro asumir que este comando se ejecuta a diario.

Solución No 1:

Dado que el usuario que crea los archivos es el que tiene el permiso para escribir en él por defecto, podemos separar los logs por usuario como tal:

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

Si su usuario de www-data creara un registro de errores, resultaría en:storage/logs/laravel-www-data-2015-4-27.log .

Si su raíz usuario fuera a crear un registro de errores, que se traduciría en: storage/logs/laravel-root-2015-4-27.log.

Solución No 2:

Cambie el registro utilizado por su comando artesanal, en su script php.

En su run()función, agregue esta línea al principio:

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

Si el nombre de su clase es ArtisanRunner, entonces su archivo de registro será:

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

Conclusión: La solución número 1 es mejor, dado que delinea sus registros por usuario y, por lo tanto, no se producirán errores.

EDITAR: Como señaló Jason, get_current_user()devuelve el nombre del propietario del script. Por lo tanto, para que se aplique la solución n. ° 1, chownsus archivos de clase artesanal se asignan al nombre de usuario requerido.

Laravel versión 5.6.10 y posterior tiene soporte para un permissionelemento en la configuración ( config/logging.php) para singley el dailycontrolador:

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

No es necesario hacer malabares con Monolog en el script de arranque.

Específicamente, se agregó soporte en https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8 .

Para Laravel 5.1, uso lo siguiente hacia la parte inferior de bootstrap/app.php(como se menciona en los documentos ):

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

Hay muchos otros controladores que puede utilizar en su lugar, por supuesto.

Para tales fines, debe utilizar ACL avanzada en sus archivos y directorios. setfaclsería tu respuesta aquí. Si desea otorgar permisos de usuario de www-data para escribir en los archivos raíz en un directorio específico, puede hacerlo así:

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

Después de emitir esto, está configurando permisos rwxpara el usuario de www-data en todos los archivos, /my/folder/sin importar quién los haya creado. Por favor, consulte esta y esta pregunta como referencia. Además, puede consultar los documentossetfacl .

Déjeme saber si esto ayuda.

Tenía esto funcionado de manera muy simple:

Me encontré con el mismo problema en Laravel 5.6

En config/logging.phpAcabo de actualizar el valor de ruta del canal de todos los días con php_sapi_name()en ella.

Esto crea un directorio separado para diferentes php_sapi_name y coloca el archivo de registro con la marca de tiempo en su directorio correspondiente.

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

Entonces para mi

• Los archivos de registro se crean en el fpm-fcgidirectorio: Registros del sitio web,owner: www-data
• Los archivos de registro se crean en el clidirectorio: desde el comando artisan (cronjob).owner: root

Más información sobre el registro de Laravel 5.6: https://laravel.com/docs/5.6/logging

Aquí está mi config/logging.phparchivo:

<?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 mí, este problema era mucho más que los permisos de registro ... Tuve problemas con cualquier cosa relacionada con el arranque / caché y las carpetas de almacenamiento donde un usuario creaba un archivo / carpeta y el otro no podía editar / eliminar debido al estándar 644 y 755 permisos.

Los escenarios típicos son:

• El archivo bootstrap / cache / compiled.php está siendo creado por el usuario de Apache, pero el usuario del compositor no puede editarlo al ejecutar el comando de instalación del compositor.

• El usuario de apache que crea un caché que no se puede borrar con el usuario del compositor

• Las temidas condiciones de carrera de troncos descritas anteriormente.

El sueño es que no importa qué usuario cree el archivo / carpeta, los otros usuarios que necesitan acceder tengan exactamente los mismos permisos que el autor original.

TL; DR?

Así es como se hace.

Necesitamos crear un grupo de usuarios compartidos llamado laravel, el grupo consta de todos los usuarios que necesitan acceso a los directorios de almacenamiento y bootstrap / cache. A continuación, debemos asegurarnos de que los archivos y carpetas recién creados tengan el grupo laravel y los permisos 664 y 775 respectivamente.

Es fácil hacer esto para archivos / directorios existentes, pero se necesita un poco de magia para modificar las reglas predeterminadas de creación de archivos / carpetas ...

## 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

Simplemente con fines de depuración, encontré que dividir los registros en usuarios cli / web + era beneficioso, así que modifiqué ligeramente la respuesta de Sam Wilson. Mi caso de uso fue que la cola se ejecutó bajo su propio usuario, por lo que ayudó a distinguir entre el usuario compositor que usa el cli (por ejemplo, pruebas unitarias) y el demonio de la cola.

$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

En nuestro caso, queríamos crear todos los archivos de registro para que todo el deploygrupo tuviera permisos de lectura / escritura. Por lo tanto, necesitábamos crear todos los archivos nuevos con 0664permisos, a diferencia del0644 predeterminados.

También agregamos un formateador para agregar nuevas líneas para una mejor legibilidad:

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

También es posible combinar esto con la respuesta aceptada

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

Una forma que no es Laravel de hacer que esto funcione es simplemente ejecutar su cronjob como www-data.

por ejemplo, /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

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

• Almacenará archivos como este: laravel-2018-01-27-cli-raph.logy laravel-2018-01-27-fpm-cgi-raph.logcuál es más legible.
• Las nuevas líneas se conservan (a partir del comportamiento predeterminado de Laravel)
• Funciona con Laravel Log Viewer

Laravel 5.6

Tienes que crear una clase para tu registrador:

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

Luego, debes registrarlo en config/logging.php:

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

Mismo comportamiento que para 5.5:

• Almacenará archivos como este: laravel-2018-01-27-cli-raph.logy laravel-2018-01-27-fpm-cgi-raph.logcuál es más legible.
• Las nuevas líneas se conservan (a partir del comportamiento predeterminado de Laravel)
• Funciona con Laravel Log Viewer

Agregue algo como lo siguiente al comienzo de su app/start/artisan.phparchivo (esto es con 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 la ruta si el archivo de registro diario que menciona no es el archivo de registro estándar de Laravel. Es posible que tampoco desee cambiar el grupo o establecer los permisos como lo estoy haciendo aquí. Lo anterior establece el grupo www-datay establece permisos de escritura de grupo. Luego agregué a mi usuario habitual alwww-data grupo para que la ejecución de comandos artesanales como mi usuario habitual todavía pueda escribir en el registro.

Un ajuste relacionado es poner lo siguiente al comienzo de su app/start/global.phparchivo:

umask(0002);

Si hace esto, la chmodlínea anterior se vuelve discutible. Con la umask configurada para esto, cualquier archivo nuevo que PHP (y por lo tanto Laravel) cree tendrá sus permisos enmascarados solo para que "otros" usuarios no tengan permisos de escritura. Esto significa que los directorios comenzarán como rwxrwxr-xy los archivos como rw-rw-r--. Entonces, si www-dataestá ejecutando PHP, cualquier caché y archivos de registro que cree serán grabables por defecto por cualquier persona en el grupo principal de ese usuario, que es www-data.

(Laravel 5.6) Recientemente me encontré con el mismo problema y simplemente configuré un comando programado para que se ejecutara /app/Console/Kernel.php.

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

Sé que es un poco exagerado, pero funciona como un encanto y no he tenido ningún problema desde entonces.

Laravel 5.4

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

añadir a la bootfunción enAppServiceProvider

Laravel 5.8

Laravel 5.8 te permite establecer el nombre de inicio de sesión config/logging.php.

Entonces, usando respuestas y comentarios anteriores, si desea nombrar su registro usando tanto el nombre de usuario real de posix como el php_sapi_name()valor, solo necesita cambiar el nombre del registro establecido. El uso del controlador diario permite la rotación de registros que se ejecuta por combinación de usuario / api, lo que garantizará que el registro siempre sea rotado por una cuenta que pueda modificar los registros.

También agregué una verificación para las funciones posix que pueden no existir en su entorno local, en cuyo caso el nombre del registro simplemente es el estándar por defecto.

Suponiendo que está utilizando el canal de registro predeterminado 'diariamente', puede modificar su clave de 'canales' así:

# 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,
    ],
    ...

Esto dará como resultado un nombre de registro que debe ser único para cada combinación, como laravel-cli-sfscs-2019-05-15.logo laravel-apache2handler-apache-2019-05-15.logsegún su punto de acceso.

Simplemente puede cambiar el permiso del archivo de registro en su comando artesanal:

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

donde get_current_user () devolverá el usuario del script actual.

En otras palabras, daily.logsiempre tendrá www-datacomo propietario, incluso si inicializa el script como rootusuario.

Si está usando Laravel Envoyer , aquí hay una posible solución al usar ACL en Linux:

1. Primero, ejecute el siguiente script con rootpermisos en el servidor:

En ambos scripts, deberá reemplazar las variables como se indica a continuación:

• {{MASTER_PATH}} : La ruta a su directorio de hosts virtuales (por ejemplo, la carpeta> que contiene su (s) aplicación (es)).
• {{WEB_SERVER_USER}} : el usuario que utiliza su servidor web.
• {{DEPLOYMENT_USER}} : el usuario que ejecuta su secuencia de comandos de implementación.

#!/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 el siguiente enlace de implementación en el enviado en "Activar nueva versión"> "Antes de esta acción

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. Vuelva a implementar su aplicación

Ahora vuelva a implementar su aplicación y debería funcionar en el futuro.

Nota: El script definido en 1. debe ejecutarse cada vez que agregue un nuevo proyecto a la máquina.

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

La mejor manera que encontré es que fideloper sugiere, http://fideloper.com/laravel-log-file-name , puede establecer la configuración del registro de laravel sin la clase de registro táctil. Tener diferentes nombres para los programas de consola y los programas Http, creo, es la mejor solución.

Esta solución definitivamente funcionará en Laravel V5.1 - V6.x

Razones de este error:

• Hay una causa principalmente debido a problemas de permisos.
• Variables de entorno no encontradas o .envarchivo no encontrado en su directorio raíz
• Problema de extensiones de PHP
• Problema de la base de datos

Reparar:

• Establezca los permisos correctos:
  • Ejecute estos 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

• Si el archivo .env no existe, cree uno touch .envy pegue las variables de entorno y luego ejecute

   php artisan key:generate
   php artisan cache:clear
   php artisan config:clear
   composer dump-autoload
   php artisan migrate //only if not already migrated