Cron Job rsync error - .meta file failed permission denied (13)

[AndyX]

I have two drives in my server. Every night I have a Cron Job which runs a rsync to backup my user folder and all folders and files below it. This has worked very well for a long time, but lately I have been getting an email indicating there is an error. Here's what the email indicates:

rsync: opendir "/backup/.meta" failed: Permission denied (13)
IO error encountered -- skipping file deletion
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1179) [sender=3.1.2]

I looked for a file called .meta but it does not exist. Is this file .meta file being created by cPanel during the running of the Cron Job?

 

[cPRex]

Hey there! /backup/.meta is a directory that gets used for metadata details related to the backup settings on the server. This will contain files named "username.db" which are databases in an SQLite format.

I don't see why an rsync command couldn't copy those normally if the command is being run as root. Is it possible you recently updated the server from an older version, or were there any other changes made to the machine?

 

[AndyX]

Thank you for looking into this, cPRex.

I don't see why an rsync command couldn't copy those normally if the command is being run as root.

When a Cron Job runs from cPanel, it will not be run as root, it will be run as Current user.

/backup/.meta is a directory that gets used for metadata details related to the backup settings on the server.

The Cron Job is running rsnc, it has nothing to do with cPanel's backup.

What I don't understand is why can't I see this .meta file when I look for it as root in the terminal?

 

[cPRex]

Since it's a hidden file you may need to specify "ls -lah" when looking for this in the terminal. Are you still not seeing it even with that command?

 

[AndyX]

Are you still not seeing it even with that command?

Correct, not seeing it using that command. Perhaps the file is being generated by cPanel when the Cron Job starts and deleted after the Cron Job is completed?

 

[cPRex]

The .meta directory wouldn't be related to the cron job at all. The cron job does try and read it, but it's something that is created by the main backup process.

Could you provide an example of the cron commands you are using so I can check this on my end?

 

[AndyX]

I appreciate your help, cPRex.

rsync -a --delete /home/southbay/ /backup

 

[cPRex]

Thanks for the additional details. By default, when I create a cPanel user and provide them with shell access, I'm not able to see the rsync command, so it seems there may be other customizations included on the system in order to get that working.

Is it possible you also recently enabled backups on the server through WHM, instead of just using this area for rsync? That would have created the .meta directory, which your cPanel user wouldn't be able to access.

 

[AndyX]

Thanks for the additional details. By default, when I create a cPanel user and provide them with shell access, I'm not able to see the rsync command, so it seems there may be other customizations included on the system in order to get that working.

I'm on a dedicated server with WHM and cPanel. I don't recall having to do anything to use rsync as a user in cPanel in a Cron Job. It would be great if you could further look into why you're not able to use it.

Is it possible you also recently enabled backups on the server through WHM, instead of just using this area for rsync? That would have created the .meta directory, which your cPanel user wouldn't be able to access.

Looking at WHM backup settings, I see this:

 

[cPRex]

So it looks like my test server was broken, and a normal cPanel user would have access to rsync if you give them shell access - sorry to lead you down the wrong path with that.

I'm not able to see that attachment, but I wouldn't recommend changing any of the backup settings on the system.

I created a new system and confirmed the user had rsync access. When running the command on my end I got the error I expected when testing this, as the user wouldn't have access to write to those directories:

[cptest@hostname backup]$ rsync -a --delete /home/cptest /backup
rsync: recv_generator: mkdir "/backup/cptest" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1179) [sender=3.1.2]

Could you let me know what you are trying to do with this rsync command? If you have automated backups running, all those files would already be in place in the backups on the system.

 

[AndyX]

Hi cPRex,

Every morning the Cron Job runs to rsync the the entire user directory and all directories and files within it. I have two drives in my server, drive A and drive B. I'm using drive B as a backup drive and that's where I have the /backup directory. The email message only started recently, within the last week or so. The Cron Job has been runiing for over a year without issues.

 

[AndyX]

I created a new system and confirmed the user had rsync access. When running the command on my end I got the error I expected when testing this, as the user wouldn't have access to write to those directories

Run the same test with the user having ownership permission to /backup/cptest directory.

 

[AndyX]

Question are you running the test in a Cron Job, or from the terminal? I have not tested in terminal, but I would assume no errors would occur.

 

[cPRex]

When logged in as the user I would expect both cron and terminal to give me the same results.

By default, /backup/username wouldn't exist unless it was created manually. If I create that and then run the command again, that works well:

[root@10-2-32-250 backup]# rsync -a --delete /home/cptest /backup
[root@10-2-32-250 backup]#

I setup a cron for the user to run this command every minute so I could see this work in real time, and that is working well according to the cron log, and I did not receive an email notification error either:

Dec 17 12:20:01 92test CROND[3590]: (cptest) CMD (rsync -a --delete /home/cptest /backup)

If you have created /backup/username and your system, and the ownership of that directory is user:user, I would expect this work well as a cron.

 

[AndyX]

When logged in as the user I would expect both cron and terminal to give me the same results.

I just tried this, like you set the Cron Job for 5 minutes, same error email sent just like if I had run it once per day.

I then tried from SSH logged in as user, no error no email. So it appears to be a cPanel issue.

 

[cPRex]

Could you get a ticket submitted so we can check that out? Please post the ticket number here so I can follow along and keep the community updated with our findings.

 

[AndyX]

Could you get a ticket submitted

I tried that once, but the process is too difficult.

Earlier I ran the Cron Job, well I looked at the cron log and perhaps this will help. What is the next line all about?

 

[cPRex]

The second line there wouldn't be related to your cron at all, but is part of the Imunify system.

I think the easiest thing to try would be modifying your command from this:

 rsync -a --delete /home/southbay/ /backup

To a specific directory, like this:

 rsync -a --delete /home/southbay/ /backup/southbay

That way it won't try and access areas it is not supposed to, and it will not interfere with other backups that might be present. You'll likely need to create /backup/southbay first before trying that.

 

[AndyX]

To fix the issue I reported in post number 1, I needed to disable metadata creation as described in this link:

How to Manage Metadata Settings | cPanel & WHM Documentation

System administrators can manage whether to create metadata for backups.

docs.cpanel.net

I added the following to the config file.



This solution works for me as I don't use any of the cPanel backup functions.

 

[cPRex]

If you aren't using any of the cPanel backup tools it's fine to disable the metadata creation. I might still recommend using a custom directory name other than "/backup" or "/backups" to avoid this confusion in the future.