Storage folder write permissions fail on newly installed Sail

[cyrrill]

• Sail Version: 1.4.9
• Laravel Version: 8.33.1
• PHP Version: 8.0
• Database Driver & Version: MySQL 8.0.23-1debian10

Description:

Unable to write to storage folder.

Steps To Reproduce:

I have installed Sail into an existing Laravel 8 application as per the installation guide. The container and associated services come up and yield no errors.

When I attempt to access the application from the browser, the exception mentioned above shows up.

Normally, all you need to do is chmod and/or chown the /storage/ folder in order for Laravel to run.

When I try to publish the Dockerfiles (in order to attempt to set permissions), I get this other exception:

 ./vendor/bin/sail artisan sail:publish -vvv

   League\Flysystem\Exception 

  Impossible to create the root directory "/var/www/html/docker/7.4".

  at vendor/league/flysystem/src/Adapter/Local.php:112
    108▕             clearstatcache(false, $root);
    109▕ 
    110▕             if ( ! is_dir($root)) {
    111▕                 $errorMessage = isset($mkdirError['message']) ? $mkdirError['message'] : '';
  ➜ 112▕                 throw new Exception(sprintf('Impossible to create the root directory "%s". %s', $root, $errorMessage));
    113▕             }
    114▕         }
    115▕     }
    116▕ 

  1   vendor/league/flysystem/src/Adapter/Local.php:133
      League\Flysystem\Adapter\Local::ensureDirectory()

  2   vendor/league/flysystem/src/Filesystem.php:102
      League\Flysystem\Adapter\Local::write()

  3   vendor/league/flysystem/src/MountManager.php:597
      League\Flysystem\Filesystem::put()

  4   vendor/laravel/framework/src/Illuminate/Foundation/Console/VendorPublishCommand.php:254
      League\Flysystem\MountManager::put()

  5   vendor/laravel/framework/src/Illuminate/Foundation/Console/VendorPublishCommand.php:238
      Illuminate\Foundation\Console\VendorPublishCommand::moveManagedFiles()

  6   vendor/laravel/framework/src/Illuminate/Foundation/Console/VendorPublishCommand.php:203
      Illuminate\Foundation\Console\VendorPublishCommand::publishDirectory()

  7   vendor/laravel/framework/src/Illuminate/Foundation/Console/VendorPublishCommand.php:166
      Illuminate\Foundation\Console\VendorPublishCommand::publishItem()

(...)

[cyrrill]

I've rebuilt the images to the PHP 7.4 version, used sail build --no-cache and the same permissions issue persists.

[driesvints]

Hi there,

Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!

Thanks.

[cyrrill]

@driesvints,
"Please only use this issue tracker for reporting bugs with the library itself."

I installed Sail exactly step by step as instructed in the official guide, and it reports a malfunction upon first use, I would classify this as a bug.

[driesvints]

@cyrrill I can write to the storage folder just fine and this is the first report we've gotten on it. Please try a support channel.

[cyrrill]

Currently on the host the storage folder is at 775, and when I chmod 777 -R storage, Sail works, but that carries the obvious security issues.

The issue appears possibly to be with the WWWGROUP & WWWUSER env vars.

WWWUSER is set to 1000 and WWWGROUP shows undefined.

Don't really have time to delve into making this work at the moment, was hoping it would work out of the box. (and it likely does for freshly installed L8 apps)

Thanks for getting back to me though, will try this another time or check on Laracasts as you suggest 👍

[cyrrill]

For reference this is not an isolated issue and has been reported before:

https://laracasts.com/discuss/channels/laravel/groupadd-invalid-group-id-sail

https://laracasts.com/discuss/channels/general-discussion/laravel-sail-cannot-mkdir-permission-denied

[MaybeThisIsRu]

@cyrrill Are you running Docker in rootless mode?

[cyrrill]

Hi @hirusi, thanks for following up on this. On first attempt I was running it as default which requires root, given that the Dockerfile requires access to port 80 which is privileged on Linux. After seeing the issue with the permissions, I installed rootless mode and allowed port 80 via net.ipv4.ip_unprivileged_port_start=0 in sysctl. The issue persists: a storage folder with 775 permissions on the host appears non-writable to the sail user inside the container. So far, the only way to allow writes to storage is by setting it to 777 on the host.

[MaybeThisIsRu]

I'm writing down my discoveries and attempts to make 775 work over here, but unfortunately, like you, I haven't had a breakthrough on a clean solution yet.

I'm not sure how far I'll push my attempts, but I have subscribed to the thread here and would love to keep up with what anyone else is attempting.

Edit: I saw you mentioned somewhere up that "it probably works fine on a fresh L8 app." That's not the case for me.

[Martijn-Bos]

This bug is also present here. I can't write to the laravel.log in the storage folder after going through the Laravel installation guide. I'm using WIN10,docker desktop+ ubuntu20.04 WSL2.

This is not an isolated incident

[NicolasPereira]

I have this problem whenever I use laravel sail, both in new and old applications!

I use Linux Ubuntu 20.04

I fix this problem these problems using inside the project repository:

$ sudo chmod -R 777 storage

I tried to write this command using sail bash and was unsuccessful!

This is not an isolated incident

[peterbabic]

I also have many many issues with permissions with:

• storage
• bootstrap/cache
• vendor/composer/autoload_namespaces.php (possibly the whole composer folder)

Not sure which user or group are these files/folders meant to belong to. No issues on a machine running Arch however.

[cyrrill]

Hi @driesvints,

There have been 4 other people having this issue. Any chance you could consider having a look again? Or at the very least update the documentation to explain how this is supposed to work?

[cyrrill]

Is chmod 777 really the only option we have?