Magento2: PHP Warning: fopen failed to open stream: Permission denied

[premgurung]

Description

after successfully installtion of magento 2 unabel to access the magento web server

error
PHP Warning: fopen(/var/www/digitivy-prodmagento/MagentoStore/var/cache//mage-tags/mage---2a5_CONFIG): failed to open stream: Permission denied in /var/www/digitivy-prodmagento/MagentoStore/vendor/colinmollenhour/cache-backend-file/File.php on line 646
[Fri Aug 18 13:20:39.957447 2017] [:error] [pid 26538] [client 10.1.1.198:56567] PHP Warning: fopen(/var/www/digitivy-prodmagento/MagentoStore/var/cache//mage-tags/mage---2a5_MAGE): failed to open stream: Permission denied in /var/www/digitivy-prodmagento/MagentoStore/vendor/colinmollenhour/cache-backend-file/File.php on line 646

Preconditions

magento 2.1
php 5.6
rds mysql 5.6

Steps to reproduce

install magento 2 prerequest and change the permission accordingly

sudo find var vendor pub/static pub/media app/etc -type f -exec chmod g+w {} \;
sudo find var vendor pub/static pub/media app/etc -type d -exec chmod g+ws {} \;
sudo chown -R magento:apache .
sudo chmod u+x bin/magento

Actual Result:

after successfull installation of the magento 2 unable to access the home page .please find the error belwo
;

PHP Warning: fopen(/var/www/digitivy-prodmagento/MagentoStore/var/cache//mage-tags/mage---2a5_CONFIG): failed to open stream: Permission denied in /var/www/digitivy-prodmagento/MagentoStore/vendor/colinmollenhour/cache-backend-file/File.php on line 646
[Fri Aug 18 13:20:39.957447 2017] [:error] [pid 26538] [client 10.1.1.198:56567] PHP Warning: fopen(/var/www/digitivy-prodmagento/MagentoStore/var/cache//mage-tags/mage---2a5_MAGE): failed to open stream: Permission denied in /var/www/digitivy-prodmagento/MagentoStore/vendor/colinmollenhour/cache-backend-file/File.php on line 646

Expected result

after successfull installation of the magento 2 able to access the home page

[orlangur]

Try to follow official manual: http://devdocs.magento.com/guides/v2.1/install-gde/prereq/file-system-perms.html

Issue is obviously with incorrectly set permissions.

[premgurung]

Hi @orlangur

even after giving proper permission still facing the issuses

useradd magento
sudo usermod -a -G apache magento
sudo usermod -aG wheel magento
cd /var/www/",{"Ref": "InstanceTagName"},"/MagentoStore
sudo find var vendor pub/static pub/media app/etc -type f -exec chmod -R g+w {} \\;
sudo find var vendor pub/static pub/media app/etc -type d -exec chmod -R g+ws {} \\;
        "sudo chown -R :apache . \n",
        "sudo chmod u+x bin/magento \n",
        "service httpd restart \n",
        "cd /var/www/",{"Ref": "InstanceTagName"},"/MagentoStore \n",
        "su magento \n",
    "cd bin \n",
                                "./magento setup:install --admin-firstname=", { "Ref" : "AdminFirstName" }, " ",
                                " --admin-lastname=", { "Ref" : "AdminLastName" }, " ",
                                " --admin-email=", { "Ref" : "AdminEMail" }, " ",
                                " --admin-user=", { "Ref" : "AdminUser" }, " ",
                                " --admin-password=", { "Ref" : "AdminPassword" }, " ",
                                " --db-name=", { "Ref" : "DBName" }, " ",
                                " --db-host=", {"Fn::GetAtt" : ["MagnetoDB", "Endpoint.Address"]}, " ", 
                                " --db-user=", { "Ref" : "DBMasterUsername" }, " ",
                                " --db-password=", { "Ref" : "DBMasterUserPassword" }," ",
                                " --db-prefix=prod_\n",

can you please help me out in that .

Regards
Prem

[orlangur]

Try to edit the file PHP Warning: fopen(/var/www/digitivy-prodmagento/MagentoStore/var/cache//mage-tags/mage---2a5_CONFIG): failed to open stream with exactly the same user running web server and spot the difference between actual/needed permissions.

[xtremeperf]

I've been experiencing some frustrating permissions issues with the var/cache/mage-tags directory since upgrading to 2.1.8 as well...

Even after setting the correct file & directory permissions as described in the devdocs, including group write permissions and enabling the SETGID flag on directories (g+ws), the var/cache/mage-tags directory will seemingly not inherit the expected permissions from it's parent directory var/cache when the Magento code creates the mage-tags directory.

Your store should work as expected in developer mode (because no caching), but upon deploying to production mode these permissions errors become a problem because the default backend file caching system (Zend extended by ColinMollenhour) will cache object data to var/cache/mage-tags and that particular directory's group permissions are set incorrectly when the mage-tags directory is created by the Magento code. At this point, if you will delete all files inside the mage-tags directory and then manually set the permissions on mage-tags to 777 with SETGID flag enabled then your store's frontend and admin should work correctly... that is until you change modes again and then the Magento code will not set the permissions properly when creating the mage-tags directory. You will need to manually correct the permissions and SETGID flag on mage-tags directory after the code creates it.

I use a dedicated Ubuntu 16.04 server on Apache and PHP 7.0.22, I use a magento user file system owner and www-data group. All files and directories have correct permissions and set to magento:www-data. The magento file system owner has a secondary group assignment of www-data and I do not use a umask. Switching over to Redis caching has eliminated these permissions bugs for me because the object data is cached to memory instead of file system. The system absolutely FLIES on Redis by the way!

I've noticed online reports of many people having this issue and it seems to affect a LOT of 2.1.8 installations using the default Zend/ColinMollenhour backend file caching system. If anyone needs more information, or would like me to duplicate this issue, please let me know. I can't find any other reason for this happening and I have not started debugging the code yet. I _think_ the section of code which performs the creating and permission setting of the mage-tags directory may be located in vendor/colinmollenhour/cache-backend-file/File.php but I'm not sure that the problem lies there.

Regards,
Doug

[xtremeperf]

Ok guys... I can confirm that this is a long standing bug in the Zend/CM default backend file caching code base. I am working on some solutions, but in the mean time I recommend that you manually set the permissions to full RWX with SETGID flag (chmod 2777 mage-tags) on the var/cache/mage-tags directory after it is created by the Magento2 app.

The app creates the directory while switching to production mode and after you attempt to open your frontend or adminhtml in a browser one time (the site will error). Be sure to remove all files inside the directory. The permissions should persist until you change modes again, or until the directory is removed and re-created by the Magento 2 app.

Regards,
Doug

[premgurung]

thank you @xtremeperf @orlangur for your valueable inputs on the above issues .

[premgurung]

After configuring the below setting in env.php for memcached

/var/www/prodmagento/MagentoStore/app/etc/env.php

'session' =>
array (
'save' => 'memcached',
'save_path' => 'cus-el-1xo8ds0jkxljy.myrysn.cfg.use1.cache.amazonaws.com:11211'
),

getting the below error
"Warning: ini_set(): Cannot find save handler 'memcached' in /var/www/prodmagento/MagentoStore/vendor/magento/framework/Session/SessionManager.php on line 536

can you guys please help me out in resolving the above issue.
Thank you in advance

Thanks and Regards
Prem

[orlangur]

@premgurung, Stack Overflow, please.

[premgurung]

Hi @xtremeperf

even after changing the permission of mage-tags (manually) no luch as of now

[root@ip-10-1-3-219 cache]# ls -ltr
total 68
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--d
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--0
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--f
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--b
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--8
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--6
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--4
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--2
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--a
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--1
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--9
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--3
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--c
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--e
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--5
drwxrwsrwx 2 magento apache 4096 Aug 24 18:21 mage-tags
drwxrwxrwx 2 apache apache 4096 Aug 24 18:21 mage--7
[root@ip-10-1-3-219 cache]#

Switching over to Redis caching has eliminated these permissions bugs for me because the object data is cached to memory instead of file system. The system absolutely FLIES on Redis by the way!

have you used Amazon Redis ??

can you please help me out in switching to Redis . Thanks in Advance

[xtremeperf]

Sorry it's taking me a while to respond... this issue turned out to be more complicated than I originally thought. I've been working on it all week and have found a good solution to use for now until I can commit some code to fix the bugs. I'll post more details in the next day or two but I'm surprised anyone has been able to install Magento and get it working at all with these permissions issues in the default backend cache. We have outdated & incompatible dependencies extending Zend framework classes, errors (bugs) in Magento framework and vendor modules, some spaghetti code and some temperamental PHP functions. :-)

Add the following configuration to your app/etc/env.php file right before the last line of );

  'cache' =>
  array (
    'frontend' =>
    array (
      'default' =>
      array (
        'backend_options' =>
        array (
          'hashed_directory_umask' => NULL,
          'directory_mode' => NULL,
          'file_mode' => NULL,
        ),
      ),
    ),
  ),

Afterwards, be sure to have the correct permissions and SETGID bit assigned to the var and var/page_cache and var/cache directories, as described in the devdocs. You can set to drwxrwsr-x. Next, run the following commands as your magento file-system user:

cd /var/www/magento2
bin/magento cache:flush
cd var
rm -R cache/*
rm -R page_cache/*
bin/magento cache:flush

After doing this, new directories created under var/cache by the magento app and crontab will have inherited permissions from their parent directory. Wait a couple minutes to let your cron jobs run. Part of this bug caused directory permissions to get reset incorrectly when cron jobs run. You can verify that it's working by looking at the permissions of var/cache/mage-tags after cron jobs run. You should see the SETGID s-flag enabled in the position that you normally see the group execution x-flag displayed.

Please report back to let me know if this solution worked for you.

Regards,
Doug

[magento-engcom-team]

@premgurung Thank you for your submission. The Magento 2 GitHub repository is used to capture code and documentation issues. Questions should be posted to a question and answer site, such as Stack Exchange and the Magento Forums, where Magento community members can quickly provide recommendations and advice.

[Dart18]

@xtremeperf I tested your fix with 2.2.0 CE and it works!
Thank you.

[tony-sar]

@magento-engcom-team
This issue seems to still exist in Magento 2.2.2 CE .
Are there any plans on fixing this bug on a new Update ?

[acejakk]

This bug is affecting me aswell in Magento 2.2.2 CE.

[bovolio]

Sorry it's taking me a while to respond... this issue turned out to be more complicated than I originally thought. I've been working on it all week and have found a good solution to use for now until I can commit some code to fix the bugs. I'll post more details in the next day or two but I'm surprised anyone has been able to install Magento and get it working at all with these permissions issues in the default backend cache. We have outdated & incompatible dependencies extending Zend framework classes, errors (bugs) in Magento framework and vendor modules, some spaghetti code and some temperamental PHP functions. :-)

Add the following configuration to your app/etc/env.php file right before the last line of );

  'cache' =>
  array (
    'frontend' =>
    array (
      'default' =>
      array (
        'backend_options' =>
        array (
          'hashed_directory_umask' => NULL,
          'directory_mode' => NULL,
          'file_mode' => NULL,
        ),
      ),
    ),
  ),

Afterwards, be sure to have the correct permissions and SETGID bit assigned to the var and var/page_cache and var/cache directories, as described in the devdocs. You can set to drwxrwsr-x. Next, run the following commands as your magento file-system user:

cd /var/www/magento2
bin/magento cache:flush
cd var
rm -R cache/*
rm -R page_cache/*
bin/magento cache:flush

After doing this, new directories created under var/cache by the magento app and crontab will have inherited permissions from their parent directory. Wait a couple minutes to let your cron jobs run. Part of this bug caused directory permissions to get reset incorrectly when cron jobs run. You can verify that it's working by looking at the permissions of var/cache/mage-tags after cron jobs run. You should see the SETGID s-flag enabled in the position that you normally see the group execution x-flag displayed.

Please report back to let me know if this solution worked for you.

Regards,
Doug

this has worked for me on magento 2.1.7 CE.
THANK YOU

[tejabhagavankollepara]

Sorry it's taking me a while to respond... this issue turned out to be more complicated than I originally thought. I've been working on it all week and have found a good solution to use for now until I can commit some code to fix the bugs. I'll post more details in the next day or two but I'm surprised anyone has been able to install Magento and get it working at all with these permissions issues in the default backend cache. We have outdated & incompatible dependencies extending Zend framework classes, errors (bugs) in Magento framework and vendor modules, some spaghetti code and some temperamental PHP functions. :-)

Add the following configuration to your app/etc/env.php file right before the last line of );

  'cache' =>
  array (
    'frontend' =>
    array (
      'default' =>
      array (
        'backend_options' =>
        array (
          'hashed_directory_umask' => NULL,
          'directory_mode' => NULL,
          'file_mode' => NULL,
        ),
      ),
    ),
  ),

Afterwards, be sure to have the correct permissions and SETGID bit assigned to the var and var/page_cache and var/cache directories, as described in the devdocs. You can set to drwxrwsr-x. Next, run the following commands as your magento file-system user:

cd /var/www/magento2
bin/magento cache:flush
cd var
rm -R cache/*
rm -R page_cache/*
bin/magento cache:flush

After doing this, new directories created under var/cache by the magento app and crontab will have inherited permissions from their parent directory. Wait a couple minutes to let your cron jobs run. Part of this bug caused directory permissions to get reset incorrectly when cron jobs run. You can verify that it's working by looking at the permissions of var/cache/mage-tags after cron jobs run. You should see the SETGID s-flag enabled in the position that you normally see the group execution x-flag displayed.

Please report back to let me know if this solution worked for you.

Regards,
Doug

Hello,
Thanks for the answer.

I am working on magento2.3.2

It's worked for me. After my 3-4 days of searching, I found this one.

Beautiful. Thanks dear

[xtremeperf]

You're welcome! I'm glad the work-around has been able to mitigate this issue for those running on older versions.

The issue has been fixed in magento/magento2#14361 by @xtremeperf in 2.2-develop branch
Related commit(s):

• 9baa83fca8a97fe4c0e02557246bdd6069a50b27

[tejabhagavankollepara]

You're welcome! I'm glad the work-around has been able to mitigate this issue for those running on older versions.

The issue has been fixed in #14361 by @xtremeperf in 2.2-develop branch
Related commit(s):

• 9baa83fca8a97fe4c0e02557246bdd6069a50b27

Hello,
It's worked but after used this code, all cache types are not enabled except compiled configuration. All are in disabled state only.