Elastic Beanstalk运行Laravel命令报错：laravel.log权限不足

Hey there, I’ve fought this exact permission headache with Laravel queues on Elastic Beanstalk before—let’s get to the root of it and fix it without resorting to risky 777 permissions.

The Core Problem #

Elastic Beanstalk runs your Laravel web app under the webapp user, but when you run php artisan queue:work via SSH or manually, you’re probably using your SSH user (like ec2-user). These two users don’t share the same file permissions by default, so your queue process can’t write to the laravel.log file owned by webapp.

Step-by-Step Solutions #

1. Fix Permissions and User Group Access

First, make sure your storage directories are owned by the correct user and group, and grant secure group write access:

# Set ownership to webapp user/group
sudo chown -R webapp:webapp /var/app/current/storage
sudo chown -R webapp:webapp /var/app/current/bootstrap/cache

# Set safe permissions (775 lets owner and group read/write, others read-only)
sudo chmod -R 775 /var/app/current/storage
sudo chmod -R 775 /var/app/current/bootstrap/cache

Then add your SSH user to the webapp group so it can write to those files:

sudo usermod -a -G webapp ec2-user

Important: Log out of SSH and log back in for the group changes to take effect, then try running php artisan queue:work again.

2. Run Queues the Elastic Beanstalk Way (Recommended)

Manually running queues via SSH isn’t scalable or reliable—use EB’s process manager to run queues automatically under the correct user context. Create a .ebextensions/queues.config file in your Laravel project root with this content:

container_commands:
  01_stop_existing_queue:
    command: "sudo pkill -f 'php artisan queue:work' || true"
    ignoreErrors: true
  02_start_queue:
    command: "nohup php artisan queue:work --daemon --sleep=3 --tries=3 > /dev/null 2>&1 &"
    leader_only: true

• This stops any stale queue processes on deployment, then starts a new one as the webapp user (so it has full access to logs and storage).
• leader_only: true ensures only one instance runs the queue if you’re using a multi-instance environment (prevents duplicate job processing).

3. Quick Test to Confirm the Issue

To verify it’s a user context problem, try running the queue as the webapp user directly:

sudo su - webapp -c "cd /var/app/current && php artisan queue:work"

If this works without permission errors, you know the issue is just the user you’re running the queue under—stick with either the group addition or the EB config solution.

Why Your Previous Fixes Didn’t Work #

When you deleted and recreated laravel.log with touch, you created it as your SSH user (e.g., ec2-user). The queue process (if run as your SSH user) might have had access temporarily, but if EB’s web process tried to write to it later, it would hit permission issues. Or if you switched users to run the queue, the file ownership didn’t match. The above solutions align all users and permissions properly.

内容的提问来源于stack exchange，提问作者Chuck Le Butt