Magento 2 Permission error - RESET
There seems to be some issue with magento after running setup:upgrade and di compile from the bin directory, Once those two commands ran. Permission and ownership seems to be reset and magento store stop working , It will work If I manually reset the permission.
See below
This is when the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username). The website is loading properly.
Now I have run the bin/magento setup:upgrade command. The ownership has now changed The website is throwing error.
magento2
bumped to the homepage by Community♦ 17 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
There seems to be some issue with magento after running setup:upgrade and di compile from the bin directory, Once those two commands ran. Permission and ownership seems to be reset and magento store stop working , It will work If I manually reset the permission.
See below
This is when the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username). The website is loading properly.
Now I have run the bin/magento setup:upgrade command. The ownership has now changed The website is throwing error.
magento2
bumped to the homepage by Community♦ 17 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
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 |
There seems to be some issue with magento after running setup:upgrade and di compile from the bin directory, Once those two commands ran. Permission and ownership seems to be reset and magento store stop working , It will work If I manually reset the permission.
See below
This is when the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username). The website is loading properly.
Now I have run the bin/magento setup:upgrade command. The ownership has now changed The website is throwing error.
magento2
There seems to be some issue with magento after running setup:upgrade and di compile from the bin directory, Once those two commands ran. Permission and ownership seems to be reset and magento store stop working , It will work If I manually reset the permission.
See below
This is when the var/generation/Magento directory is owned by sohaib/www-data (sohaib is my current username). The website is loading properly.
Now I have run the bin/magento setup:upgrade command. The ownership has now changed The website is throwing error.
magento2
magento2
edited May 15 '16 at 2:53
Sohaib Khan
asked May 10 '16 at 0:28
Sohaib KhanSohaib Khan
192218
192218
bumped to the homepage by Community♦ 17 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 17 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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-permission-error-reset%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
329121
329121
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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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,1171227
1,1171227
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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4:40
you should start using Mage 2.. after 1-2 Magento will stop supporting 1.9x, its worth to go for Mage2 as it has better scope & features
– Mohammad Mujassam
May 11 '16 at 4: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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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-permission-error-reset%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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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