RSynch job giving error rsync: chgrp "." (in MediaBackup12TB) failed: Operation not permitted (1)

1. offizieller Beitrag

    I have a Open Media Vault v 6.9.11-4 that holds media for a Plex server. I have it backup via rsynch to a Synology NAS with a 12TB drive.


    I recently added the 12TB drive after an array failed, and I moved the existing rsynch'ed files from the old array to the new drive (interally on the NAS) and modified the rsynch task on the OMV NAS. The previous job had been running fine for a year or better.


    The job works, but I get several errors like the one in the subject. Most of the time it appears to be for a folder: "rsync: chgrp "Movies" (in MediaBackup12TB) failed: Operation not permitted (1)" though it then copies files into that folder just fine. Other times there's the same error for a specific file, but the file is listed with a strange extension, e.g. "rsync: chgrp "Movies/.videoname.mp4.Ah14SH" (in MediaBackup12TB) failed: Operation not permitted (1)" None of these files with the strange extension exist.


    I use the GUI for everything, and have no real idea what the rsynch errors are telling me let alone what these mystery files are.


    Any suggestions or assistance in understanding the situation is MUCH appreciated!

    • Offizieller Beitrag

    Can you post a screenshot with the rsync job scheduled? Hide sensitive information. passwords, etc. if they exist.

    MickBurke In addition to the info chente asked for, it would be useful to know what filesystem is in use on OMV ( ext4?) and what was/is used on your Synology NAS before and after the array failed as the later change seems to have triggered your problem.


    Zitat von MickBurke

    ... I get several errors like the one in the subject. Most of the time it appears to be for a folder: "rsync: chgrp "Movies" (in MediaBackup12TB) failed: Operation not permitted (1)" though it then copies files into that folder just fine. Other times there's the same error for a specific file, but the file is listed with a strange extension, e.g. "rsync: chgrp "Movies/.videoname.mp4.Ah14SH" (in MediaBackup12TB) failed: Operation not permitted (1)" None of these files with the strange extension exist.! ....

    The file "Movies/.videoname.mp4.Ah14SH" is a dot or hidden file and depending how you searched for it on Synology may not have been visible and so may exist.

    Thanks to both of you!

    I've attached two screenshots of the task.


    I also looked through the folder where there were failure and didn't see the . dotted files either in the synology file station or in windows with the 'show hidden files' on (though I couldn't figure out where the 'show hidden files' option was on synology?).


    All three file systems are ext4 (were on the failed one as I removed it after transferring).


    If any of this adds up to anything for you let me know.


    Thanks much!!


    • Offizieller Beitrag
    Zitat von MickBurke

    I recently added the 12TB drive after an array failed, and I moved the existing rsynch'ed files from the old array to the new drive (interally on the NAS) and modified the rsynch task on the OMV NAS. The previous job had been running fine for a year or better.

    In which NAS did you replace that 12TB drive? On OMV or Synology? What type of array? mdadm?


    Running tasks in push mode usually causes permissions problems. You are copying data from OMV (with OMV permissions) to Synology. If Synology does not recognize these permissions you will have problems. You can use the extra options in the rsync job to modify those permissions to match the permissions recognized in Synology.


    I'm surprised you don't use the Delete parameter. If you do it this way you will have many duplicate files with different versions, even files that were deleted in the source will be kept in the destination.

    The synology was a 4 drive SHR raid . One of them went bad, and I replaced IT with the 12TB drive and then moved everything for the degraded array to the 12 TB single drive.

    Once that was moved I removed the degraded array and modified the task on OMV (to the new share location / name) and restarted it.


    I thought the Delete parameter deleted files that didn't exist on the source but do on the destination? More like an actual synch. I don't want to do that, the whole point is if something gets deleted from the main system, I've got it on the backup.

    Every now and then if I clear out stuff on the media server (source) I go through the backup and remove them and any other incidentals . Though this makes me think I could automate that by turning 'delete' on and running the job once then switch it back off again.


    Anyway, the original goal was to avoid having to rsynch EVERYTHING to the new drive from the OMV to keep it simple, but I think I may have done the complete opposite!


    But looking at the options (which I just used the defaults when I set it up I think) I'm wondering if I turn off the Preserve permissions, group and owner options if that might help?


    Thanks again!

    • Offizieller Beitrag

    I would try to solve these problems by doing the work in Pull mode. For this, the copy should be made from Synology by copying the existing data in OMV to Synology.

    If I remember correctly in the Synology options there was a way to access a generic rsync module (not generated by another Synology server). This option was not easy to find, in its eagerness to prevent the use of other operating systems, Synology establishes childish prohibitions such as hiding these options, you will have to look for it. All this nonsense on Synology's part is what pushed me to finally sell that second-hand server years ago and set up a second OMV server as a backup that can work perfectly with the main OMV server as well.

    Then the job would be to create an rsync module in OMV and configure the rsync copy from Synology. This will cause the permissions to be set by Synology, since it is the one doing the file copying work.


    We didn't get round to establishing just how many errors are being reported, nor if any of the errant files/dirs can be safely deleted from the Synology. Without knowing the permissions of the folder/files you listed on both OMV and Synology you won't know why you are seeing the "chgrp" ( change group) error. So a push of data from OMV to Synology may not necessarily always generate errors.

    Zitat von chente

    Synology establishes childish prohibitions such as hiding these options...

    Yea, I've always marveled at some of the things Synology does, and the ways they do it. I have a few of them as 'hand me downs' from clients who retired them. If I could just wipe their os and install OMV I'd rather!

    Zitat von Krisbee

    We didn't get round to establishing just how many errors are being reported, nor if any of the errant files/dirs can be safely deleted from the Synology.

    Is there any easy way to find these files? It seems to be a lot, and I can't even establish if the .dotted files are there (some remnant of the move) or something that's being generated during the rsynch (temp file of some sort) or what they might be. Searched around a bit, but couldn't find an answer... May just wipe it and start over at this point. I've kinda wasted enough of our time on keeping this 'simple' already!

    Thanks again!

    • Offizieller Beitrag
    Zitat von MickBurke

    Movies/.videoname.mp4.Ah14SH

    I've seen files look like this when an rsync sync breaks. That file corresponds to the temporary file that rsync writes until the copy of that file is completed, then the file is renamed/deleted.

    If a synchronization is cut, that file remains in the destination. If you run rsync again, that file is deleted since it does not exist in the source.

    Since in your case you have the delete option disabled, those files would still be there after an interrupted synchronization.

    So a full sync with active delete should delete all those files.

    Thanks again, I decided to just wipe it and start clean. It seemed between all the failures, and whatever originally triggered it (moving the files from the old to the new?) the best idea was to get a clean start with the job that rand flawlessly until a drive failed and I played around with it.


    Thanks for all your help it was enlightening one way or another!

    FYI, I recreated this share completely wiped the drive etc, and the first time I ran the job I got a couple of the chgrp errors. I switched off the 'preserve permissions' etc and it has run just fine since, so it looks like it is something with the synology permissions.

    Thanks again for all your help!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden