How to Properly Set Destination Permissions (chown/chmod) When Using rsync for File Transfers


2 views

When transferring files between systems using rsync, permission handling can be particularly tricky. The issue you're experiencing with permissions defaulting to 760 and root ownership is actually quite common among sysadmins working with rsync.

The --chown and --chmod flags in rsync are powerful but need proper understanding:

--chown=USER:GROUP   # Sets owner and group
--chmod=MODE         # Sets permissions (D=dirs, F=files)
--perms (-p)         # Preserves source permissions
--owner (-o)         # Preserves owner
--group (-g)         # Preserves group

Your command is close but missing a critical component: the --no-perms flag is likely interfering, or the syntax needs adjustment. The 760 permissions suggest the execute bit isn't being set properly despite your 770 request.

Here's the corrected version that should work:

rsync -rtlv --chown=process:sambausers --chmod=Dg+rwx,ug+rwx,o-rwx,Fg+rw,ug+rw,o-rw --no-perms /mnt/owncloud_mnt/Engineering/ /Drive_D/docs/Engineering_test

For more precise control, you might prefer this format:

rsync -rtlv --chown=process:sambausers --chmod=D770,F770 --perms /source /destination
  • Ensure the target user/group exists on the destination system
  • The executing user must have sufficient privileges for chown operations
  • Remote transfers require proper ssh configuration
  • Consider using --super for recursive ownership changes

Always test with --dry-run first:

rsync -rtlvn --chown=process:sambausers --chmod=D770,F770 /source /destination

For complex permission scenarios, consider:

rsync -aAXv --chown=user:group --numeric-ids /source /destination

When using rsync for local file transfers, permission handling can become particularly tricky. The scenario where files end up with root ownership despite specifying --chown often occurs due to how rsync interacts with the underlying filesystem.

The main issues typically stem from:

  • Filesystem restrictions on the destination
  • Insufficient rsync flags for permission preservation
  • Order of operations during the sync process

Here's a working command that properly handles permissions:

rsync -avX --chown=process:sambausers --chmod=D770,F770 \
      --no-perms --no-owner --no-group \
      /mnt/owncloud_mnt/Engineering/ \
      /Drive_D/docs/Engineering_test

-X: Preserves extended attributes
--no-perms: Lets --chmod handle permissions
--no-owner/--no-group: Allows --chown to work properly

When dealing with stubborn permission issues, consider this two-step method:

# First sync without permission changes
rsync -av /source/ /destination/

# Then apply permissions recursively
chown -R process:sambausers /destination
find /destination -type d -exec chmod 770 {} \;
find /destination -type f -exec chmod 770 {} \;

Case 1: If files remain root-owned, check:

  • Destination filesystem permissions
  • Whether the target user/group exists
  • SELinux contexts if applicable

Case 2: For permission bits not applying:

# Verify filesystem mount options
mount | grep Drive_D
# Expected output should include acl or other permission-related options

For complex permission structures, consider using rsync with --fake-super:

rsync -avX --fake-super --chown=user:group \
      --chmod=Du=rwx,Dg=rwx,Do=rx,Fu=rw,Fg=rw,Fo=r \
      /source/ /destination/