Hi, when i am trying to upgrade my cs-cart ultimate 4.2.4 to 4.3.1 then i am getting this error:
------------------
Error
[color=#B94A48]Unfortunately, you cannot proceed with the upgrade because we cannot access thevar/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php file, which is used to roll back the upgrade. We must be sure that the restore functionality works fine before you continue with the upgrade.[/color]
[color=#B94A48]It seems that wrong permissions settings cause this issue.[/color][list]
Try this: []Set 644 permissions for the var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php file (chmod 644 var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php)
[]Set 755 permissions for var/ , var/upgrade/ , var/upgrades/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz folders (chmod -R 755 ./var)
[*]Click the Install button to restart the upgrade procedure.
[/list]
[color=#B94A48]If this error message occurs after you have completed the above steps, contact our support team via your Help Desk account and give them a temporary SSH or FTP access to your store.[/color]
----------------------------
i have tried to fix all file permissions as per the instructions… but still have same problem.
also my config.local.php file have:
define('DEFAULT_FILE_PERMISSIONS', 0644);
define('DEFAULT_DIR_PERMISSIONS', 0755);
i have also tried “chmod -R 777 var design images”, still the same.
also tried these:
find * -type f | xargs chmod 644
find * -type d | xargs chmod 755
and still the same.
i am running my website on a amazon ec2 instance with cpanel-whm.
Please help me fix this problem.
Naman
skype: elcotek
info@elcotek.net
I have the same problem, I open a ticket, do you solve it?
Set 755 permissions for var/
Set 755 permissions forvar/upgrade/
Set 755 permissions for var/upgrades/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz
I did mine today and I also had a very large list of files that didn't have sufficient permissions. I used my FTP editor to change the permissions for the specific folders. I changed them to 777 and set it recursive so it would change permissions for all files within that folder. For the individual files within the root, I changed them to 777 for the upgrade and then changed them back to 644 once the upgrade was complete.
Hi friends,
Same for me = exactly same message than nonu-don. I modified the chmod as wanted, but now, I have this message :[color=#B94A48]
Erreur_unable_to_unpack_file[/color][color=#B94A48]
×ErreurFailed to extract files from the archive[/color]
[quote name='TienDung_vn' timestamp='1432744902' post='216040']
Set 755 permissions for var/
Set 755 permissions forvar/upgrade/
Set 755 permissions for var/upgrades/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz
[/quote]
There is no such thing as /var/upgrades (plural) - in my server.
There is /var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz - can anyone confirm there is an /upgrades/ there?
This error can be caused by incorrect permissions, but can also occur if you're working on a password protected DEV site (i.e. passworded via apache). We were able to proceed with the upgrade by temporarily disabling the password.
It must be trying to test access to the restore script by making an HTTP GET request, and failing due to the password. Much the same as when you try to enable HTTPS on a password protected DEV site and it's HTTPS test fails.
Hope this helps, Happy Fruit Bat.
Same problem here and still no help from support. Has anyone figured this out yet?
Hello!
The upgrade script checks that the revert.php script is accessible using GET request (it is logged and you can see this request on the Administration > Logs page of your admin panel). If the script is not accessible, you see the mentioned notice.
In most cases the fact that the script is not accessible means that incorrect permissions are set for the file and/or the directories where it is located. On most servers 644/755 permissions will do the trick, however, it strongly depends on server configuration. If the notice appears after changing permissions, we recommend to contact your server administrator and consult about the permissions that should be used on your server.
Please note that you can check if the script is accessible or not by opening the following link in your browser:
http://your_domain/var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php
If you see “Access denied”, then permissions are ok and the file is accessible (sic!).
We hope this will help you.
—
Anastasiya Kozlova
CS-Cart Support team
[quote name='TienDung_vn' timestamp='1432744902' post='216040']
Set 755 permissions for var/
Set 755 permissions forvar/upgrade/
Set 755 permissions for var/upgrades/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz
[/quote]
OK, TienDung_VN
--------------------------
Chuẩn cmnr
[quote name='nastena' timestamp='1433857723' post='218027']
Please note that you can check if the script is accessible or not by opening the following link in your browser:
http://your_domain/var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php
If you see “Access denied”, then permissions are ok and the file is accessible (sic!).
[/quote]
Hi Anstasiya, I want to make sure I understand correctly, seeing “Access denied” on restore.php is a normal behaviour? I have followed pretty much everything that was mentioned in this thread however I keep getting:
Error[color=#B94A48]
Unfortunately, you cannot proceed with the upgrade because we cannot access thevar/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz/restore.php file, which is used to roll back the upgrade. We must be sure that the restore functionality works fine before you continue with the upgrade.[/color]
When I check apache access logs, restore.php returns 200 message however I am seeing 404 Not Found error message in Admin → Logs. This is really confusing.
755 permissions and all the other settings have been applied but nothing seems to be helping.
Thanks
I had the same error when upgrading from 4…2.4 to 4.3.1 and I was able to fix it by doing the permission changes and removing the protected directory since our site is for internal use only.
I kept getting following errors and I went through each folder one by one and change the write settings.
[error] SoftException in Application.cpp:668: Directory “/home3/public_html/test/var” is writeable by group
[error] SoftException in Application.cpp:668: Directory “/home3/public_html/test/var/upgrade” is writeable by group
[error] [client 192.185.237.14] SoftException in Application.cpp:677: Directory “/home3/public_html/test/var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz” is writeable by others
[error] [client 192.185.237.14] SoftException in Application.cpp:668: Directory “/home3/public_html/test/var/upgrade/upgrade_4.2.4_ultimate-4.3.1_ultimate.tgz” is writeable by group
What webserver are you using. This doesn't look like Apache so assuming NGIX?
Get to a shell prompt on your server.
$ cd [root of your store]
$ find * -type d | xargs chmod 755
and you should be all set.
Make sure you change the the line that looks like
define('DEFAULT_DIR_PERMISSIONS', 0777);
to
define('DEFAULT_DIR_PERMISSIONS', 0755);
in config.local.php so that the upgrade doesn't try to create new files with inappropriate permissions for your site.
Hi tbirnseth, thanks for the response. It was a problem with server configuration. Got it figured out.
Thanks for the tip on the default configuration setting terrible permissions, I had no idea (WTF is up with that anyway?!?).
The file and folder permissions within /var/upgrade were a mishmash of nonsense. Once I standardzied them to 755/644, my Internal Server Error worries went away. What's up with the mishmash of permissions, purposefully breaking the upgrade process to generate service income? Pulling a PrestaShop? Tsk tsk…
One of our customers receive the message; Page not found.
The update file is also missing. what now?
Just saw the questions under this thread. I believe I changed the folder permissions to 755. Normally, /var/ folder is expected to be 777 but for some reason for upgrade to work, you have to make sure 'Group' bit in folder permission is not able to write and it is 755. If not, try other combinations, you will find it.
All depends on what "mode" you use for PHP. suPHP will fail if directories are 777 as will fastCGI.
DSO will accept it.
The critical issue is file/directory ownership. It should be correct for your site configuration. Ask your host what it should be for your site and then ensure that any FTP accounts that access the site are setup to create files with correct ownership.