Skip to main content

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

Comments

24 comments

  • cPRex Jurassic Moderator
    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?
    0
  • 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?
    0
  • cPRex Jurassic Moderator
    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?
    0
  • 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?
    0
  • cPRex Jurassic Moderator
    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?
    0
  • AndyX
    I appreciate your help, cPRex. rsync -a --delete /home/southbay/ /backup
    0
  • cPRex Jurassic Moderator
    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.
    0
  • 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:
    0
  • cPRex Jurassic Moderator
    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.
    0
  • 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.
    0
  • 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.
    0
  • 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.
    0
  • cPRex Jurassic Moderator
    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.
    0
  • 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.
    0
  • cPRex Jurassic Moderator
    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.
    0
  • 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?
    0
  • cPRex Jurassic Moderator
    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.
    0
  • AndyX
    To fix the issue I reported in post number 1, I needed to disable metadata creation as described in this link:
    0
  • cPRex Jurassic Moderator
    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.
    0
  • AndyX
    Adding DISABLE_METADATA: yes
    did not work. I got another email this morning when the Cron Job ran. I just updated the Cron Job, it will now hopefully exclude the /backup/.meta directory. Here's what I have now and will see tomorrow morning if I get another email: rsync -a --delete --exclude '/backup/.meta' /home/southbay/ /backup
    0
  • AndyX
    Unfortunately the above --exclude did not work. This morning I got the same email message: 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]
    0
  • cPRex Jurassic Moderator
    I still don't believe that using /backup is ever going to provide an ideal experience, as that may also get used for actual backup data. I'd recommend a different directory name to place these files in and then you won't run into the issues.
    0
  • AndyX
    I still don't believe that using /backup is ever going to provide an ideal experience, as that may also get used for actual backup data. I'd recommend a different directory name to place these files in and then you won't run into the issues.

    You were 100% correct, Rex. I changed the Cron Job to the following and no more error emails. rsync -a --delete /home/southbay/ /backup/southbay
    Thank you for your help.
    0
  • cPRex Jurassic Moderator
    Great - I'm glad that's all it took!
    0

Please sign in to leave a comment.