Linux rsync Error: ‘Some Files Could Not Be Transferred, Permissions Denied’ on CentOS Stream / Rocky Linux

Resolve rsync permission errors on CentOS Stream & Rocky Linux. This guide covers common causes like user context, file ownership, and SELinux, providing step-by-step fixes.

Resolve rsync permission errors on CentOS Stream & Rocky Linux. This guide covers common causes like user context, file ownership, and SELinux, providing step-by-step fixes.

rsync is an indispensable utility for synchronizing files and directories, widely used for backups, migrations, and deployment. However, encountering "some files could not be transferred" errors, especially those related to permissions, can halt critical operations. This guide delves into common permission-related rsync failures on CentOS Stream and Rocky Linux environments, providing a comprehensive troubleshooting approach.

Symptom & Error Signature

When running an rsync command, files fail to transfer, and you observe error messages indicating permission issues. This typically results in an rsync exit code 23 or 24.

You might see output similar to this:

rsync -avzP /source/data/ user@remote:/destination/backup/

receiving incremental file list
rsync: [sender] chgrp "/destination/backup/file1.txt" failed: Operation not permitted (1)
rsync: [sender] chown "/destination/backup/file1.txt" failed: Operation not permitted (1)
rsync: [sender] chmod "/destination/backup/file1.txt" failed: Operation not permitted (1)
rsync: [receiver] failed to set permissions on "/destination/backup/file1.txt": Permission denied (13)
rsync: [receiver] failed to set times on "/destination/backup/file1.txt": Permission denied (13)
rsync: [receiver] mkdir "/destination/backup/new_directory" failed: Permission denied (13)
rsync error: some files could not be transferred (code 23) at main.c(1814) [sender=3.2.7]
rsync error: some files could not be transferred (code 23) at io.c(882) [receiver=3.2.7]

The key indicators are "Operation not permitted (1)", "Permission denied (13)", and the rsync exit code 23 (Partial transfer due to error) or 24 (Partial transfer due to vanished source files).

Root Cause Analysis

Permission errors during rsync operations typically stem from a mismatch between the permissions required by rsync to operate and the permissions available to the user executing the command on either the source or destination system. On CentOS Stream and Rocky Linux, the situation is often compounded by SELinux.

  1. Insufficient User Permissions (Source/Destination):
    • Source: The user running rsync lacks read access to files or execute access to directories within the source path.
    • Destination: The user running rsync (or the SSH user for remote transfers) lacks write access to the destination directory or execute access to intermediate directories to create new files/directories. This is the most common cause.
  2. Incorrect File Ownership: Even if permissions (e.g., rwx) seem correct, if the destination user is not the owner or a member of the owning group, they might not be able to modify ownership or groups of transferred files. rsync -a attempts to preserve ownership.
  3. SELinux Context Mismatch: This is a frequent culprit on CentOS/Rocky. SELinux (Security-Enhanced Linux) provides mandatory access control (MAC), which can override traditional Linux discretionary access control (DAC). Even if chmod and chown settings allow access, SELinux might prevent a process from writing to a directory if the file's or directory's security context (e.g., httpd_sys_content_t) doesn't match the process's allowed contexts.
  4. Immutable Files/Directories: Less common, but files or directories marked as immutable using chattr +i cannot be modified, deleted, or renamed even by root.
  5. Access Control Lists (ACLs): If standard chmod permissions seem correct but access is still denied, ACLs might be in effect, providing finer-grained permissions that override or supplement standard permissions.
  6. Filesystem-Specific Limitations: When synchronizing to/from mounted network filesystems (NFS, SMB/CIFS), the server-side permissions and how they map to the client user can cause issues.

Step-by-Step Resolution

Follow these steps to diagnose and resolve rsync permission errors, starting with the most common issues.

1. Verify Source Read Permissions

Ensure the user executing rsync has read access to all files and execute access to all directories in the source path.

# Check current user (relevant for local source)
whoami

# List permissions recursively for the source path
ls -laR /source/data/

If the rsync command is being run as userA but /source/data/file.txt is owned by root:root with rw------- permissions, userA will be denied.

Action:

  • Adjust permissions with chmod and chown if necessary, or
  • Run rsync as a user with appropriate read permissions (e.g., root via sudo).

2. Verify Destination Write Permissions and Ownership

This is the most common point of failure. The user connecting to the remote host (or the local user for local transfers) must have write and execute permissions on the destination directory.

# On the destination server (if remote) or locally
whoami # Identify the user that rsync is running as

# Check permissions of the destination directory and its parent directories
# Use -d to check the directory itself, not its contents
ls -ld /destination/backup/
ls -ld /destination/
ls -ld /

# Check owner and group
ls -ld /destination/backup/

Look for w (write) permission for the user, group, or others, and x (execute) for directories.

Action:

  • Adjust ownership:
    sudo chown -R your_user:your_group /destination/backup/
  • Adjust permissions:
    sudo chmod -R u+rwX,g+rX,o-rwx /destination/backup/ # Example: Owner read/write/execute, Group read/execute, Others no access
# Or, if directory needs full group write access (e.g., for shared web content)
sudo chmod -R g+w /destination/backup/

    The X in u+rwX automatically applies execute permission only to directories, not files. This is generally a good practice for chmod.

3. Address SELinux Contexts

SELinux is a mandatory access control system vital for security on CentOS/Rocky Linux. It often blocks actions even when standard chmod and chown appear correct.

# Check SELinux status
sestatus

# List SELinux contexts for the destination directory
ls -Zd /destination/backup/

If SELinux is enforcing and the context of /destination/backup/ (e.g., unconfined_u:object_r:default_t:s0) does not match the expected context for the service accessing it (e.g., httpd_sys_content_t for a web server, rsync_data_t for rsync operations in an rsync daemon setup), access can be denied.

Action (Recommended order):

  1. Restore default SELinux contexts: This is often sufficient if files were moved or created with incorrect contexts.

    sudo restorecon -Rv /destination/backup/

    This command recursively scans the directory and restores file contexts to their default based on system policy.

  2. Manually set contexts (if restorecon is not enough): If the directory is intended for a specific service, you might need to set a persistent context.

    # Example for web content
sudo semanage fcontext -a -t httpd_sys_content_t "/destination/backup(/.*)?"
sudo restorecon -Rv /destination/backup/

# Example for general rsync data (if using rsync daemon)
sudo semanage fcontext -a -t rsync_data_t "/destination/backup(/.*)?"
sudo restorecon -Rv /destination/backup/

  3. Temporarily set SELinux to Permissive mode (for diagnosis ONLY):

    Setting SELinux to permissive mode significantly reduces system security. ONLY do this temporarily for diagnosis, and re-enable enforcing mode immediately after testing. Never leave it in permissive mode on a production system.

    sudo setenforce 0
# Re-run your rsync command. If it works, SELinux was the culprit.
sudo setenforce 1 # Re-enable enforcing mode immediately!

    If setenforce 0 resolves the issue, you must then identify and apply the correct SELinux context or policy rule, rather than disabling SELinux.

4. Leverage rsync Options for Permissions

rsync provides several options to control how permissions, ownership, and timestamps are handled. Understanding these is crucial.

  • -a (Archive mode): This is commonly used and implies -rlptgoD.

    • r: recursive
    • l: links as links
    • p: preserve permissions
    • t: preserve times
    • g: preserve group
    • o: preserve owner
    • D: preserve devices, sparseness If the destination user cannot preserve ownership/group/permissions, -a will cause errors (e.g., "chown failed: Operation not permitted").

  • --no-p, --no-g, --no-o: These explicitly tell rsync not to preserve permissions, groups, or ownership respectively. This is often the solution if the remote user doesn't have the privileges to set ownership/permissions as per the source. The files will be created with the permissions and ownership of the user running rsync on the destination.

    rsync -avzP --no-o --no-g /source/data/ user@remote:/destination/backup/

    Or, if you also don't care about preserving specific permissions (e.g., creating new files with default umask):

    rsync -avzP --no-p --no-o --no-g /source/data/ user@remote:/destination/backup/
# This is equivalent to rsync -rtD, often combined with -vP

  • --chown=USER:GROUP: Force a specific owner and group on the destination, regardless of the source. The rsync user on the destination must have permission to chown files.

    rsync -avzP --chown=apache:apache /source/data/ user@remote:/destination/backup/

  • --chmod=MODE: Force specific file permissions on the destination.

    rsync -avzP --chmod=Du=rwx,Dg=rX,Fu=rw,Fg=r /source/data/ user@remote:/destination/backup/
# Du=rwx: Directories owner rwx
# Dg=rX: Directories group r-x (X for execute on directories only)
# Fu=rw: Files owner rw
# Fg=r: Files group r

5. Check for Immutable Files

Files or directories marked as immutable cannot be changed, deleted, or renamed even by root.

# Check for immutable flag on destination files/directories
lsattr /destination/backup/your_file.txt
# Output like: ----i--------e-- /destination/backup/your_file.txt indicates immutable

lsattr -d /destination/backup/your_directory/
# Output like: ----i--------e-- /destination/backup/your_directory/ indicates immutable

Action:

  • Remove the immutable flag:
    sudo chattr -i /destination/backup/your_file.txt
sudo chattr -i /destination/backup/your_directory/

6. Advanced: Access Control Lists (ACLs)

If standard chmod and chown adjustments don't resolve the issue, and SELinux is not the problem, ACLs might be in play. ACLs allow more granular permission settings than traditional Unix permissions.

# Check ACLs on the destination directory
getfacl /destination/backup/

If getfacl shows specific user: or group: entries that deny access, you'll need to modify them.

Action:

  • Modify ACLs (e.g., to grant write access to a specific user):
    sudo setfacl -m u:your_user:rwx /destination/backup/
  • Remove specific ACLs:
    sudo setfacl -x u:offending_user /destination/backup/
  • Remove all ACLs:
    sudo setfacl -b /destination/backup/

7. Final Check: Dry Run

Before committing to a full rsync transfer after making changes, always perform a dry run to see what rsync would do.

rsync -avzP --dry-run /source/data/ user@remote:/destination/backup/

The --dry-run (or -n) option will show you the actions rsync plans to take, including any permission errors it would encounter, without actually transferring or modifying files. This is invaluable for verifying your fixes.