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;
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
add a comment |
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
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
add a comment |
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
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
magento2 cli file-permissions setup-upgrade setup-di-compile
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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
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
add a comment |
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.
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
|
show 1 more comment
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
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
|
show 1 more comment
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.
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
|
show 1 more comment
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.
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.
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
|
show 1 more comment
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
|
show 1 more comment
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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