Cómo solucionar Permission Denied en Laravel storage/logs (Guía 2026)

El error “Permission Denied” en storage/logs es uno de los más comunes en proyectos con Laravel.
Suele aparecer después de subir el proyecto a producción, cambiar de servidor o instalar dependencias.

En esta guía aprenderás:

• Por qué ocurre el error
• Cómo solucionarlo paso a paso
• Comandos correctos para Linux
• Solución en hosting compartido
• Cómo evitar que vuelva a ocurrir

¿Por qué aparece el error Permission Denied en Laravel?

En esta sección entenderás la causa real del problema para evitar soluciones temporales.

Laravel necesita permisos de escritura en estas carpetas:

storage/
bootstrap/cache/

Cuando el servidor (Apache o Nginx) no puede escribir en storage/logs, aparece el error:

The stream or file ".../storage/logs/laravel.log" could not be opened in append mode: Permission denied

La causa más común es:

• Usuario incorrecto
• Permisos mal configurados
• Archivos subidos por otro usuario (ej: root)

Solución rápida en servidor Linux (VPS o dedicado)

Aquí aplicamos la solución correcta usando comandos seguros en sistemas Linux.

Si tienes acceso SSH, ejecuta:

sudo chown -R www-data:www-data storage
sudo chown -R www-data:www-data bootstrap/cache

sudo chmod -R 775 storage
sudo chmod -R 775 bootstrap/cache

Nota:
En algunos servidores el usuario puede ser:

• apache
• nginx
• www-data

Puedes verificarlo con:

ps aux | grep apache

Si no tienes acceso root, aquí te explico cómo hacerlo manualmente.

Si usas paneles como:

• cPanel
• HestiaCP

Haz lo siguiente:

1. Entra al administrador de archivos
2. Ve a la carpeta storage
3. Cambia permisos a 755 o 775
4. Marca opción recursiva

Si sigue fallando, prueba 775.

🚫 No uses 777 en producción.

¿Por qué NO debes usar chmod 777?

Aunque parece solución rápida, puede comprometer la seguridad del servidor.

Muchos tutoriales recomiendan:

chmod -R 777 storage

Pero esto:

• Permite escritura total a cualquier usuario
• Es riesgoso en servidores compartidos
• Puede permitir ejecución maliciosa

La configuración recomendada es:

775

Verifica que el usuario sea correcto

A veces el problema no es el permiso, sino el propietario del archivo.

Ejecuta:

ls -la

Si los archivos pertenecen a root,Laravel no podrá escribir.

Solución:

sudo chown -R tuusuario:tuusuario storage

En hosting compartido normalmente no ocurre este problema.

Limpiar caché después de corregir permisos

Después de arreglar permisos, limpia la caché para evitar errores persistentes.

Ejecuta:

php artisan config:clear
php artisan cache:clear
php artisan config:cache

Verificar versión compatible de PHP

Asegúrate de que tu versión de PHP sea compatible con tu versión de Laravel.

Por ejemplo:

• Laravel 12 → PHP 8.2+
• Laravel 11 → PHP 8.2+

Puedes verificar tu versión:

php -v

Solución definitiva recomendada (configuración ideal)

Esta es la configuración profesional usada en producción.

sudo chown -R www-data:www-data /var/www/tu-proyecto
sudo find /var/www/tu-proyecto -type f -exec chmod 644 {} \;
sudo find /var/www/tu-proyecto -type d -exec chmod 755 {} \;

sudo chmod -R 775 storage
sudo chmod -R 775 bootstrap/cache

Esto:

• Mantiene seguridad
• Permite escritura
• Evita errores futuros

Cómo evitar que vuelva a ocurrir

Descripción: Buenas prácticas para no repetir el error en futuros despliegues.

1. No subir archivos como root
2. Usar el mismo usuario del servidor
3. Configurar permisos antes de publicar
4. Automatizar despliegue con script

Preguntas frecuentes

¿Este error afecta solo a production?

No, también puede pasar en local si usas Docker o WSL.

¿Pasa en Windows?

En Windows es menos común porque maneja permisos diferente.

Caso Practico en Hosting

Se migro de Hosting un sistema en producción y en el otro hosting ya no quiso levantar nos salia este error.

la solución es:

Borrar la cache en la carpeta bootstrap.

Una vez dentro de la carpeta botstrap/cache, borraremos esos 3 archivos:

• config.php
• packpage.php
• services.php

Conclusión

El error Permission Denied en Laravel storage/logs ocurre por permisos mal configurados o propietario incorrecto.

La solución correcta es:

1. Ajustar propietario (chown)
2. Asignar permisos seguros (775)
3. Limpiar caché
4. Verificar usuario del servidor

Si aplicas esta configuración, el error no debería volver a aparecer.

Para resumir uno de los mas sencillo es limpiar la cache de storage y bootstrap de laravel