Easyadminbundle: [BUG] symfony console cache:clear write folder with 775 rights

Created on 9 Dec 2017  路  19Comments  路  Source: EasyCorp/EasyAdminBundle

Hi,

When I run the php bin/console cache:clear command, the easyadmin cache folder under var/cache/dev/easyadmin is created with 775 rights instead of 777.
So When I go on the web page I get:
The directory "my_path_to/var/cache/dev/easy_admin" is not writable.
As if the umask(0000); from the console didn't work?

I tracked the issue to the CacheManager class, calling the parent::construct of FilesystemCache with no $umask third parameter. That third parameter is 0002 by default in the FilesystemCache construct.

But I think if it was really an issue with the bundle, someone else would have reported it by now. Maybe I lack some conf?

bug unconfirmed

Most helpful comment

I'm closing this issue because we're starting a new phase in the history of this bundle (see #2059). We've moved it into a new GitHub organization and we need to start from scratch: no past issues, no pending pull requests, etc.

I understand if you are angry or disappointed by this, but we really need to "reset" everything in order to reignite the development of this bundle.

All 19 comments

P.S. I hacked it temporarily with that:
public function __construct($cacheDir) { if (($_SERVER['APP_ENV'] ?? 'dev')==='dev') { parent::__construct($cacheDir, self::EXTENSION,0000); }else{ parent::__construct($cacheDir); } }

Not sure what to say ... I haven't experience this error ever and I don't remember any reported issue about this. But it looks important enough to keep investigating it.

My configuration:

  • VirtualBox on Windows 10
  • ElementaryOs on VirtualBox
  • Apache: Server version: Apache/2.4.29 (Ubuntu) - Server built: 2017-12-13T08:13:20
  • PHP: PHP 7.2.0-2+ubuntu16.04.1+deb.sury.org+2 (cli) (built: Dec 7 2017 20:14:31) ( NTS )

What are other useful informations I could provide?

Some screenshoot:

capture d ecran du 2017-12-17 14 14 04
capture d ecran du 2017-12-17 14 11 56

EDIT:
I tested on Windows and no problems (as to be expected with Windows right management)

Having same issue here

  • VMware Workstation on Windows 10
  • Debian 9 on VMware Workstation
  • Nginx: Server version: 1.12.2-1~stretch
  • PHP-FPM: 7.2.0-1+0~ 20171201111333.14+stretch~1.gbp47ee8a

Having the same issue, php7.1 on mac locally, apache installed. Solve it with a 'sudo chmod -R 777 var/cache/' after each cache:clear, but annoying

Same problem on archlinux, I have to do sudo chmod -R 777 var/cache/' after each cache:clear .....

Any news about this issue?

I ran composer update but I still have the issue

I submitted a pull request to fix this (#1965) but nobody has reviewed or tested or commented on it yet.

Update: sorry, I linked to the wrong pull request.

Some of you showed that running a chmod -R 777 var/cache/ solved the problem ... but we'd need to know the cause of this problem. I don't suffer this issue so for me it's hard to debug. I'd need your help. Thanks.

What informations would be useful?
I just installed it from composer, add my entity to the config file, and that's it.

Having the issue as well.

Thing I notice is that the easy_admin folder is the ONLY folder without a write permission for everyone. See screenshot below. This is the result just after a cache:clear --env=dev command.

Specs:
Ubuntu 16.04.3 LTS
setfacl commands executed as documented
easy_admin installed using flex

image

If you need more info let me know.

I also have the same problem, on both Linux and Windows.

I'm closing this issue because we're starting a new phase in the history of this bundle (see #2059). We've moved it into a new GitHub organization and we need to start from scratch: no past issues, no pending pull requests, etc.

I understand if you are angry or disappointed by this, but we really need to "reset" everything in order to reignite the development of this bundle.

From Symfony 4, all plugins/bundles should rely on cache warmup to write on cache (see https://symfony.com/doc/current/setup/file_permissions.html).

Hey @javiereguiluz !

I have the same problem and I'm pretty sure it comes from virtualized environments (or similar environments) as the user of the webserver does not have the permissions to write the cache cleared by the console/user manually.

However as @ebuildy said, we should rely on Symfony caching features handling this for us. Let's discuss this :) (here or on Slack if you want).

I don't use virtualized/containarized apps, so I'm afraid I can't fix this myself. If anyone with experience knows how to solve this, please send a pull request and I'll help reviewing it, testing it (in non-virtualized apps), etc. Thanks a lot!!

I'll have a look :) .

IMHO this fix will work only if you explicit set APP_ENV variable to 'dev' (so Symfony environment is 'dev').
But by default in Symfony if APP_ENV is missing then Symfony environment is also 'dev' - fix is not working in this situation.
According to https://symfony.com/doc/current/setup/file_permissions.html Symfony use umask(0000), so fix should be like this:
if (!umask()) { parent::__construct($cacheDir, self::EXTENSION, 0000); } else { parent::__construct($cacheDir); }

Was this page helpful?
0 / 5 - 0 ratings