7

I have a seedbox-account which I use for torrenting. I have set up a cron job that uses rsync to download all files from the seedbox to my 14.04.1 ubuntu server. The download folder is a samba share, as I have previously used windows to organize the content into folders before moving it to a more permanent place on my server. Before upgrading to 14.04, I used 12.04 and everything worked OK.

The problem is that the files I get from the seedbox is owned by a user called "544" (this is the username generated by the seedbox, not some octal thing) and can not be deleted by my user on my server. After changing permissions on the download folder, I can delete them. Also, I have given all users permissions to read/write in the samba folder upon sharing it.

So my question is this: Is it possible through some elegant command executed to make rsync change user/permissions on the files when downloading it? Or is it possible to make the folder function in a way that all new files will automatically change user when copied/moved to it? I guess I could put the chmod command in sudo cron to run every once in a while to change the owner of the files, but since sometimes the amount of data to be downloaded can be rather large, it is difficult to know when to trigger it in relation to the rsync-job to make sure all files are downloaded.

| improve this question | |
15

rsync only preserves the owner if you ask it to with -o — otherwise files will be owned by the user running the rsync command, just like when any other files are created. -a includes -o, however, so lots of common rsync command lines include it. man rsync includes a passage on this explicitly:

For example: if you want to use -a (--archive) but don’t want -o
(--owner),  instead  of  converting  -a  into -rlptgD, you could
specify -a --no-o (or -a --no-owner).

So instead of rsync -a source dest you can use rsync -a --no-o source dest to have files be owned by the user running the command.

On the other hand, you can usually only change the owner of a file if you're root, so this doesn't come up much. If it's necessary to run this job as root for some reason, and you want the files to be owned by your normal user rather than root, you can use the --chown option:

rsync -a --chown=youruser:yourgroup ...

There is also a --usermap option for more complicated mappings, if you do want to keep some users. It takes a comma-separated list of from:to pairs.

As a final option, since you're apparently running rsync from a cron job, you can just append the owner/permissions-changing operation to the cron job with && chown ....

| improve this answer | |
  • 1
    The --chmod option of rsync may also be of interest, since only root can change the ownership of files on most systems. – D_Bye Aug 4 '14 at 9:24
  • 1
    The --chmod option was added with rsync version 3.1. For example debian ships from jessie with that version. – rethab Jul 6 '15 at 12:58
  • Also it seems like both client and server should be running 3.1.0+ in order to use --chown. – Jacket Mar 11 '16 at 7:05
0

I tested some ways but in my case the result of e.g. this script 

rsync -a -v --progress --modify-window=1 -c -b -i -s -m --del -vv --ignore-errors --chmod=ugo=rwx --delete --delete-excluded  --exclude='*~'  --exclude='.*' --backup-dir=.rsync_bak /home/test /media/user/usb_ext4

was that the permission cannot be wider than the permission of the partition / target where the file should be written to. (Check those permissions after mounting the device)

| improve this answer | |
  • That's quite complex rsync command, with some redundant and self-inconsistent options: for example, only either -v (verbose) or -vv (very verbose) should be necessary. Also, --modify-window=1 should be useless when -c says modification time should not be considered in comparision: the content should be always checksummed. And the "permission cannot be wider than permission of the target" sounds like a filesystem-specific issue: are you rsyncing to a VFAT filesystem by chance? – telcoM Jan 4 '18 at 22:21
  • I'm trying for vfat, fuseblk, ext3, ext4... Sure your are right that commands appear to be redundant. But like you said - only on the input command level but not any more at the execution of this command. The sequence of commands determines the real execution. Because I haven´t found an [profound] overview about which commands have to be written exactly in a specific order and or right after another option - I´m testing a few combinations .. – InLaw Jan 11 '18 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.