Can't create a system backup

Magento 2
1
  1. Dedicated Server at OVH
  2. I use Platinum Server Management & have the sever 5 years
    • CENTOS 6.10 [server] * [v78.0.18], Apache/2.4.38; PHP 7.0
  4. Magento 2.2.7

I’m trying to create a system backup prior to upgrading to 2.3
I am getting the error “You need more permissions to create a backup”
I can create a database backup.

I am logged in as the administrator. Originally when I installed Magento with an installer I went with the suggested installation folder magento2/. I wanted the installation in the root so later moved it to the root. I did see later that 2 cron jobs were set up referencing this now deleted folder. I edited the target url and fixed that. I am wondering if the renaming has caused an issue with permissions. (I am assuming the permissions error is a server issue).

2

Hi, I’ve ran into the same issue while back. Although it started bit differently and I am running Ubuntu I had the same message pop up at some point.
You can check out this topic: Magento backup problem perhaphs you have something set wrong and you will find answer there. However, it didn’t really help me. To fix my problem I had to change file permission which is not a recommended solution to any problem.
I have used this post: https://stackoverflow.com/questions/3740152/how-do-i-change-permissions-for-a-folder-and-all-of-its-subfolders-and-files-in to change files and directories permissions to 664 and 775 respectively only in magento root directory. As I mentioned it is not recommended but it helped me in a short run.

3

Sounds like it’s either an Owner or Permissions issue. My var/backups folder is set to ‘770’ which grants both Read and Write Permissions to both the magento user and www-data.

When you execute a Backup via the Web Setup Wizard, you’re relying on Cron to have the correct permissions to make the changes required to complete the job. Therefore, there’s 2 checks you could do:

Permissions
First, set your backups folder to the correct Permissions (if they aren’t already). Run as magento user from Magento root directory:

chmod 770 var/backups/

Ownerships
You may also need to verify that your backups folder has the correct ownership. So, for example if you ever created that file as root user then neither your magento user or www-data user would be able to write to the folder regardless or whether it was set to 770 or not.

Running the below as any user from the Magento root directory will display the Owner / Group of the backups folder:

ls -la var/

You should see something like this:

magento@M23:~/html$ ls -la var/
drwxrwsr-x 16 www-data www-data   20480 Mar 25 15:33 .
drwxrwxr-x 16 www-data www-data    4096 Mar 25 01:00 ..
drwxrwsr-x  2 www-data www-data    4096 Feb  4 14:02 backups

If it’s wrong then you’ll need to reset the Owner of the folder. Run the following as superuser or root user from the Magento root directory:

sudo chown www-data:www-data var/backups/

Cron
Second, ensure that your Cron Tasks are running under the correct user. Run the following as magento user:

crontab -l

You should see something like this:

* * * * * /usr/bin/php /var/www/html/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /var/www/html/var/log/magento.cron.log
* * * * * /usr/bin/php /var/www/html/update/cron.php >> /var/www/html/var/log/update.cron.log
* * * * * /usr/bin/php /var/www/html/bin/magento setup:cron:run >> /var/www/html/var/log/setup.cron.log

Important Notes

  • On Centos with Apache, I think the Group is apache instead of www-data. Check first before running any commands
  • magento user is the user who primarily owns the files. So substitute this with whatever username you’re using for the magento user
  • Double-check all commands you see here before using them (in case of typos)
4

Hi Craig,

Thanks for the reply.

I’ve set the permissions for var/backups/ to 770.

Running ‘ls -la var/’ gives me the cPanel username as both the Owner and Group. Is this correct?

5

Cool. I think that Owner/Group might be right, but I have no way of knowing as your setup is unique to you. So assuming that your Owner/Group is “bob” and that’s the user you’re also logged in as, then running crontab -l should produce similar results as what I mentioned before.

Then in theory you should be good to go.

6

I have been away so sorry for late reply. The error still persists but have moved the development site from our unmanaged OVH server to a managed VPS with Fastcomet. I am going to get these guys to sort it Hopefully it serves as a good indicator of what they can do. Just bedding it in and their support response has been very fast.

7

Sure, no problem. If you find out, let me know what the issue was after they fix it for you.

8

This is a bit embarrassing and a mystery, thus even more embarassing.

From Fastcomet support.

"The warning occured due to the .htaccess file inside the /app/etc folder was missing, thus I added the .htaccess file with the correct rules which deny public access.

Once I completed the above the warning was removed,"

9

Ha :slight_smile: At least it was a nice easy fix. Thanks for keeping us posted.