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

AndyX

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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?
 
Last edited:

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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?
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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:

1608220542970.png
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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:

Code:
[[email protected] 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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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.
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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:

Code:
[[email protected] backup]# rsync -a --delete /home/cptest /backup
[[email protected] 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:

Code:
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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
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

Jurassic Moderator
Staff member
Oct 19, 2014
6,874
908
313
cPanel Access Level
Root Administrator
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:

Code:
 rsync -a --delete /home/southbay/ /backup
To a specific directory, like this:

Code:
 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

Well-Known Member
Sep 25, 2015
104
13
68
Los Altos, CA
cPanel Access Level
Root Administrator
To fix the issue I reported in post number 1, I needed to disable metadata creation as described in this link:


I added the following to the config file.

1608297074739.png

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