Magento 2: How to fix incorrect permissions after executing setup:upgrade and/or setup:di:compileMagento 2 folder/file permissionsMerged JS and CSS do not work when Production modePermission change after setup:upgradeUnable to enable the Apache2 user www-dataRunning “bin/magento setup:static-content:deploy” gives “Permission denied”Digital Ocean Droplet Magento 2 Extension not recognized after setup:upgradeFatal error: Uncaught Error: Class 'Cli' not foundError when running bin/magento setup:upgrade after creating Module on Magento 2getting error: Class MagentoIndexerModelResourceModelIndexerStateCollectionFactory does not existhow to solve Readiness Check errors when installing extension magento 2.0.4?Magento2 Installation Error by 0%Command line user does not have read and write permissions on generated directory. Please address this issue before using Magento command lineMagento 2 : Error 500 after installing

Are there moral objections to a life motivated purely by money? How to sway a person from this lifestyle?

A faster way to compute the largest prime factor

Combinatorics problem, right solution?

Does the damage from the Absorb Elements spell apply to your next attack, or to your first attack on your next turn?

Unknown code in script

How to have a sharp product image?

Multiple options vs single option UI

What to do with someone that cheated their way through university and a PhD program?

Why is the underscore command _ useful?

Retract an already submitted recommendation letter (written for an undergrad student)

A strange hotel

A ​Note ​on ​N!

What does a straight horizontal line above a few notes, after a changed tempo mean?

How important is it that $TERM is correct?

Can I criticise the more senior developers around me for not writing clean code?

How bug prioritization works in agile projects vs non agile

How exactly does Hawking radiation decrease the mass of black holes?

Older movie/show about humans on derelict alien warship which refuels by passing through a star

What is the unit of time_lock_delta in LND?

Will I lose my paid in full property

Nails holding drywall

Was Dennis Ritchie being too modest in this quote about C and Pascal?

Could moose/elk survive in the Amazon forest?

Magical attacks and overcoming damage resistance



Magento 2: How to fix incorrect permissions after executing setup:upgrade and/or setup:di:compile


Magento 2 folder/file permissionsMerged JS and CSS do not work when Production modePermission change after setup:upgradeUnable to enable the Apache2 user www-dataRunning “bin/magento setup:static-content:deploy” gives “Permission denied”Digital Ocean Droplet Magento 2 Extension not recognized after setup:upgradeFatal error: Uncaught Error: Class 'Cli' not foundError when running bin/magento setup:upgrade after creating Module on Magento 2getting error: Class MagentoIndexerModelResourceModelIndexerStateCollectionFactory does not existhow to solve Readiness Check errors when installing extension magento 2.0.4?Magento2 Installation Error by 0%Command line user does not have read and write permissions on generated directory. Please address this issue before using Magento command lineMagento 2 : Error 500 after installing






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








4















After running setup:upgrade and di compile from the bin directory, permission and ownership is reset and the magento store stops working. It works if I manually reset the permission.



When the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username) the website is loading properly.



When I run the bin/magento setup:upgrade command, the ownership has changed and the website is throwing errors.










share|improve this question
























  • You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

    – mrtuvn
    May 10 '16 at 4:18


















4















After running setup:upgrade and di compile from the bin directory, permission and ownership is reset and the magento store stops working. It works if I manually reset the permission.



When the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username) the website is loading properly.



When I run the bin/magento setup:upgrade command, the ownership has changed and the website is throwing errors.










share|improve this question
























  • You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

    – mrtuvn
    May 10 '16 at 4:18














4












4








4








After running setup:upgrade and di compile from the bin directory, permission and ownership is reset and the magento store stops working. It works if I manually reset the permission.



When the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username) the website is loading properly.



When I run the bin/magento setup:upgrade command, the ownership has changed and the website is throwing errors.










share|improve this question
















After running setup:upgrade and di compile from the bin directory, permission and ownership is reset and the magento store stops working. It works if I manually reset the permission.



When the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username) the website is loading properly.



When I run the bin/magento setup:upgrade command, the ownership has changed and the website is throwing errors.







magento2 cli file-permissions setup-upgrade setup-di-compile






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 21 at 14:07









Joshua Flood

371224




371224










asked May 10 '16 at 0:28









Sohaib KhanSohaib Khan

307419




307419












  • You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

    – mrtuvn
    May 10 '16 at 4:18


















  • You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

    – mrtuvn
    May 10 '16 at 4:18

















You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

– mrtuvn
May 10 '16 at 4:18






You have to re-deploy and chmod after that! chmod -R 777 var/* in your current root magento directory

– mrtuvn
May 10 '16 at 4:18











2 Answers
2






active

oldest

votes


















2














With regards to Mohammad's answer, permissions should never be set to 777.



The problem here is that newly generated files are owned by the user and group who issues the command $USER:$USER, where they should belong to $USER:www-data or $USER:apache. Because apache2 does not have access to the group $USER, the website cannot be properly served.



In order to retain proper permissions, magento commands should be executed as the apache user.



For example:



Ubuntu



$ sudo -u www-data php bin/magento setup:upgrade



CentOS



$ sudo -u apache php bin/magento setup:upgrade



This way, new files are owned by www-data:www-data (in the case of ubuntu).



So long as you have properly followed Magento's documentation with regards to permissions and added the cli user to the apache2 group, then you will have proper access to the files.



If you did not follow this documentation then you can execute the following command to do so:



Ubuntu



$ sudo usermod -a -G www-data $USER



CentOS



$ sudo usermod -a -G apache $USER



Note:



In order that commands can be executed without declaring the apache2 user, Daniel's answer explains that we can modify how the Magento framework sets permissions for new files.



If you are having trouble installing/updating via composer or deploying to production, then you can simply grant ownership of any inaccessible files (these are highlighted yellow in the terminal) to www-data by issuing the following command:




sudo chown www-data:www-data "/absolute/path/to/file.json"




Then, follow BrunoBueno's answer, applying the above fix:



$ sudo -u www-data bin/magento setup:upgrade
$ sudo -u www-data bin/magento indexer:reindex
$ sudo -u www-data bin/magento deploy:mode:set production -s
$ sudo -u www-data bin/magento setup:di:compile (Here was the secret, to run the di:compile after production)
$ sudo -u www-data bin/magento setup:static-content:deploy





share|improve this answer




















  • 1





    Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

    – Jan Tomka
    Jul 13 '18 at 11:35











  • I have just been working on that. Will edit the answer now to include the solution...

    – Joshua Flood
    Jul 18 '18 at 16:57


















-1














Just change the permission of magento's Var from Magento root directory...



Run below command from magento root:



chmod -R 777 var/



if still you are getting same error then change the permission of full magento directory as per magento official document.



Magento file system ownership and permissions



Hope this will resolve your problem.






share|improve this answer























  • That's what I've been doing , is that normal

    – Sohaib Khan
    May 10 '16 at 10:28











  • Is this the same case with Debian or Centos

    – Sohaib Khan
    May 10 '16 at 12:07











  • I didn't check that but most probably as both are same kind of OS

    – Mohammad Mujassam
    May 10 '16 at 12:37











  • You think it's worth it to stay with Mage 1.9x or Mage 2

    – Sohaib Khan
    May 10 '16 at 12:55






  • 1





    You shouldn't use 777. See my answer.

    – Joshua Flood
    Jun 2 '18 at 19:40











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "479"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f114623%2fmagento-2-how-to-fix-incorrect-permissions-after-executing-setupupgrade-and-or%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














With regards to Mohammad's answer, permissions should never be set to 777.



The problem here is that newly generated files are owned by the user and group who issues the command $USER:$USER, where they should belong to $USER:www-data or $USER:apache. Because apache2 does not have access to the group $USER, the website cannot be properly served.



In order to retain proper permissions, magento commands should be executed as the apache user.



For example:



Ubuntu



$ sudo -u www-data php bin/magento setup:upgrade



CentOS



$ sudo -u apache php bin/magento setup:upgrade



This way, new files are owned by www-data:www-data (in the case of ubuntu).



So long as you have properly followed Magento's documentation with regards to permissions and added the cli user to the apache2 group, then you will have proper access to the files.



If you did not follow this documentation then you can execute the following command to do so:



Ubuntu



$ sudo usermod -a -G www-data $USER



CentOS



$ sudo usermod -a -G apache $USER



Note:



In order that commands can be executed without declaring the apache2 user, Daniel's answer explains that we can modify how the Magento framework sets permissions for new files.



If you are having trouble installing/updating via composer or deploying to production, then you can simply grant ownership of any inaccessible files (these are highlighted yellow in the terminal) to www-data by issuing the following command:




sudo chown www-data:www-data "/absolute/path/to/file.json"




Then, follow BrunoBueno's answer, applying the above fix:



$ sudo -u www-data bin/magento setup:upgrade
$ sudo -u www-data bin/magento indexer:reindex
$ sudo -u www-data bin/magento deploy:mode:set production -s
$ sudo -u www-data bin/magento setup:di:compile (Here was the secret, to run the di:compile after production)
$ sudo -u www-data bin/magento setup:static-content:deploy





share|improve this answer




















  • 1





    Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

    – Jan Tomka
    Jul 13 '18 at 11:35











  • I have just been working on that. Will edit the answer now to include the solution...

    – Joshua Flood
    Jul 18 '18 at 16:57















2














With regards to Mohammad's answer, permissions should never be set to 777.



The problem here is that newly generated files are owned by the user and group who issues the command $USER:$USER, where they should belong to $USER:www-data or $USER:apache. Because apache2 does not have access to the group $USER, the website cannot be properly served.



In order to retain proper permissions, magento commands should be executed as the apache user.



For example:



Ubuntu



$ sudo -u www-data php bin/magento setup:upgrade



CentOS



$ sudo -u apache php bin/magento setup:upgrade



This way, new files are owned by www-data:www-data (in the case of ubuntu).



So long as you have properly followed Magento's documentation with regards to permissions and added the cli user to the apache2 group, then you will have proper access to the files.



If you did not follow this documentation then you can execute the following command to do so:



Ubuntu



$ sudo usermod -a -G www-data $USER



CentOS



$ sudo usermod -a -G apache $USER



Note:



In order that commands can be executed without declaring the apache2 user, Daniel's answer explains that we can modify how the Magento framework sets permissions for new files.



If you are having trouble installing/updating via composer or deploying to production, then you can simply grant ownership of any inaccessible files (these are highlighted yellow in the terminal) to www-data by issuing the following command:




sudo chown www-data:www-data "/absolute/path/to/file.json"




Then, follow BrunoBueno's answer, applying the above fix:



$ sudo -u www-data bin/magento setup:upgrade
$ sudo -u www-data bin/magento indexer:reindex
$ sudo -u www-data bin/magento deploy:mode:set production -s
$ sudo -u www-data bin/magento setup:di:compile (Here was the secret, to run the di:compile after production)
$ sudo -u www-data bin/magento setup:static-content:deploy





share|improve this answer




















  • 1





    Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

    – Jan Tomka
    Jul 13 '18 at 11:35











  • I have just been working on that. Will edit the answer now to include the solution...

    – Joshua Flood
    Jul 18 '18 at 16:57













2












2








2







With regards to Mohammad's answer, permissions should never be set to 777.



The problem here is that newly generated files are owned by the user and group who issues the command $USER:$USER, where they should belong to $USER:www-data or $USER:apache. Because apache2 does not have access to the group $USER, the website cannot be properly served.



In order to retain proper permissions, magento commands should be executed as the apache user.



For example:



Ubuntu



$ sudo -u www-data php bin/magento setup:upgrade



CentOS



$ sudo -u apache php bin/magento setup:upgrade



This way, new files are owned by www-data:www-data (in the case of ubuntu).



So long as you have properly followed Magento's documentation with regards to permissions and added the cli user to the apache2 group, then you will have proper access to the files.



If you did not follow this documentation then you can execute the following command to do so:



Ubuntu



$ sudo usermod -a -G www-data $USER



CentOS



$ sudo usermod -a -G apache $USER



Note:



In order that commands can be executed without declaring the apache2 user, Daniel's answer explains that we can modify how the Magento framework sets permissions for new files.



If you are having trouble installing/updating via composer or deploying to production, then you can simply grant ownership of any inaccessible files (these are highlighted yellow in the terminal) to www-data by issuing the following command:




sudo chown www-data:www-data "/absolute/path/to/file.json"




Then, follow BrunoBueno's answer, applying the above fix:



$ sudo -u www-data bin/magento setup:upgrade
$ sudo -u www-data bin/magento indexer:reindex
$ sudo -u www-data bin/magento deploy:mode:set production -s
$ sudo -u www-data bin/magento setup:di:compile (Here was the secret, to run the di:compile after production)
$ sudo -u www-data bin/magento setup:static-content:deploy





share|improve this answer















With regards to Mohammad's answer, permissions should never be set to 777.



The problem here is that newly generated files are owned by the user and group who issues the command $USER:$USER, where they should belong to $USER:www-data or $USER:apache. Because apache2 does not have access to the group $USER, the website cannot be properly served.



In order to retain proper permissions, magento commands should be executed as the apache user.



For example:



Ubuntu



$ sudo -u www-data php bin/magento setup:upgrade



CentOS



$ sudo -u apache php bin/magento setup:upgrade



This way, new files are owned by www-data:www-data (in the case of ubuntu).



So long as you have properly followed Magento's documentation with regards to permissions and added the cli user to the apache2 group, then you will have proper access to the files.



If you did not follow this documentation then you can execute the following command to do so:



Ubuntu



$ sudo usermod -a -G www-data $USER



CentOS



$ sudo usermod -a -G apache $USER



Note:



In order that commands can be executed without declaring the apache2 user, Daniel's answer explains that we can modify how the Magento framework sets permissions for new files.



If you are having trouble installing/updating via composer or deploying to production, then you can simply grant ownership of any inaccessible files (these are highlighted yellow in the terminal) to www-data by issuing the following command:




sudo chown www-data:www-data "/absolute/path/to/file.json"




Then, follow BrunoBueno's answer, applying the above fix:



$ sudo -u www-data bin/magento setup:upgrade
$ sudo -u www-data bin/magento indexer:reindex
$ sudo -u www-data bin/magento deploy:mode:set production -s
$ sudo -u www-data bin/magento setup:di:compile (Here was the secret, to run the di:compile after production)
$ sudo -u www-data bin/magento setup:static-content:deploy






share|improve this answer














share|improve this answer



share|improve this answer








edited Jul 18 '18 at 17:03

























answered Apr 24 '18 at 10:34









Joshua FloodJoshua Flood

371224




371224







  • 1





    Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

    – Jan Tomka
    Jul 13 '18 at 11:35











  • I have just been working on that. Will edit the answer now to include the solution...

    – Joshua Flood
    Jul 18 '18 at 16:57












  • 1





    Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

    – Jan Tomka
    Jul 13 '18 at 11:35











  • I have just been working on that. Will edit the answer now to include the solution...

    – Joshua Flood
    Jul 18 '18 at 16:57







1




1





Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

– Jan Tomka
Jul 13 '18 at 11:35





Makes sense. But how do you run deploy:mode:set, which also updates the env.php file? I get "Deployment config file env.php is not writable."

– Jan Tomka
Jul 13 '18 at 11:35













I have just been working on that. Will edit the answer now to include the solution...

– Joshua Flood
Jul 18 '18 at 16:57





I have just been working on that. Will edit the answer now to include the solution...

– Joshua Flood
Jul 18 '18 at 16:57













-1














Just change the permission of magento's Var from Magento root directory...



Run below command from magento root:



chmod -R 777 var/



if still you are getting same error then change the permission of full magento directory as per magento official document.



Magento file system ownership and permissions



Hope this will resolve your problem.






share|improve this answer























  • That's what I've been doing , is that normal

    – Sohaib Khan
    May 10 '16 at 10:28











  • Is this the same case with Debian or Centos

    – Sohaib Khan
    May 10 '16 at 12:07











  • I didn't check that but most probably as both are same kind of OS

    – Mohammad Mujassam
    May 10 '16 at 12:37











  • You think it's worth it to stay with Mage 1.9x or Mage 2

    – Sohaib Khan
    May 10 '16 at 12:55






  • 1





    You shouldn't use 777. See my answer.

    – Joshua Flood
    Jun 2 '18 at 19:40















-1














Just change the permission of magento's Var from Magento root directory...



Run below command from magento root:



chmod -R 777 var/



if still you are getting same error then change the permission of full magento directory as per magento official document.



Magento file system ownership and permissions



Hope this will resolve your problem.






share|improve this answer























  • That's what I've been doing , is that normal

    – Sohaib Khan
    May 10 '16 at 10:28











  • Is this the same case with Debian or Centos

    – Sohaib Khan
    May 10 '16 at 12:07











  • I didn't check that but most probably as both are same kind of OS

    – Mohammad Mujassam
    May 10 '16 at 12:37











  • You think it's worth it to stay with Mage 1.9x or Mage 2

    – Sohaib Khan
    May 10 '16 at 12:55






  • 1





    You shouldn't use 777. See my answer.

    – Joshua Flood
    Jun 2 '18 at 19:40













-1












-1








-1







Just change the permission of magento's Var from Magento root directory...



Run below command from magento root:



chmod -R 777 var/



if still you are getting same error then change the permission of full magento directory as per magento official document.



Magento file system ownership and permissions



Hope this will resolve your problem.






share|improve this answer













Just change the permission of magento's Var from Magento root directory...



Run below command from magento root:



chmod -R 777 var/



if still you are getting same error then change the permission of full magento directory as per magento official document.



Magento file system ownership and permissions



Hope this will resolve your problem.







share|improve this answer












share|improve this answer



share|improve this answer










answered May 10 '16 at 4:33









Mohammad MujassamMohammad Mujassam

1,2321327




1,2321327












  • That's what I've been doing , is that normal

    – Sohaib Khan
    May 10 '16 at 10:28











  • Is this the same case with Debian or Centos

    – Sohaib Khan
    May 10 '16 at 12:07











  • I didn't check that but most probably as both are same kind of OS

    – Mohammad Mujassam
    May 10 '16 at 12:37











  • You think it's worth it to stay with Mage 1.9x or Mage 2

    – Sohaib Khan
    May 10 '16 at 12:55






  • 1





    You shouldn't use 777. See my answer.

    – Joshua Flood
    Jun 2 '18 at 19:40

















  • That's what I've been doing , is that normal

    – Sohaib Khan
    May 10 '16 at 10:28











  • Is this the same case with Debian or Centos

    – Sohaib Khan
    May 10 '16 at 12:07











  • I didn't check that but most probably as both are same kind of OS

    – Mohammad Mujassam
    May 10 '16 at 12:37











  • You think it's worth it to stay with Mage 1.9x or Mage 2

    – Sohaib Khan
    May 10 '16 at 12:55






  • 1





    You shouldn't use 777. See my answer.

    – Joshua Flood
    Jun 2 '18 at 19:40
















That's what I've been doing , is that normal

– Sohaib Khan
May 10 '16 at 10:28





That's what I've been doing , is that normal

– Sohaib Khan
May 10 '16 at 10:28













Is this the same case with Debian or Centos

– Sohaib Khan
May 10 '16 at 12:07





Is this the same case with Debian or Centos

– Sohaib Khan
May 10 '16 at 12:07













I didn't check that but most probably as both are same kind of OS

– Mohammad Mujassam
May 10 '16 at 12:37





I didn't check that but most probably as both are same kind of OS

– Mohammad Mujassam
May 10 '16 at 12:37













You think it's worth it to stay with Mage 1.9x or Mage 2

– Sohaib Khan
May 10 '16 at 12:55





You think it's worth it to stay with Mage 1.9x or Mage 2

– Sohaib Khan
May 10 '16 at 12:55




1




1





You shouldn't use 777. See my answer.

– Joshua Flood
Jun 2 '18 at 19:40





You shouldn't use 777. See my answer.

– Joshua Flood
Jun 2 '18 at 19:40

















draft saved

draft discarded
















































Thanks for contributing an answer to Magento Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f114623%2fmagento-2-how-to-fix-incorrect-permissions-after-executing-setupupgrade-and-or%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Sum ergo cogito? 1 nng

三茅街道4182Guuntc Dn precexpngmageondP