Fixing ‘rsync error some files could not be transferred permissions’ on Ubuntu 22.04 LTS

Troubleshoot and resolve rsync permission errors on Ubuntu 22.04 LTS. Learn to set correct file/directory ownership and permissions for successful data transfers.

Troubleshoot and resolve rsync permission errors on Ubuntu 22.04 LTS. Learn to set correct file/directory ownership and permissions for successful data transfers.

Introduction

As a seasoned Systems Administrator, encountering permission issues during data synchronization is a common hurdle. The rsync utility, a cornerstone for efficient file transfer and synchronization, can report errors such as "some files could not be transferred" or "Permission denied" when it lacks the necessary privileges to read from the source or, more frequently, to write to the destination. This guide will walk you through diagnosing and resolving these permission-related rsync failures on Ubuntu 22.04 LTS, ensuring your synchronization tasks complete successfully.

Symptom & Error Signature

When rsync encounters permission problems, you'll typically see error messages indicating a failure to access files or directories. The most common scenario involves the rsync process being unable to create, modify, or delete files on the destination system.

Here are typical error outputs you might observe:

rsync -avz /source/path/ user@remote:/destination/path/

sending incremental file list
rsync: [sender] chdir "/source/path/some_directory" failed: Permission denied (13)
rsync: [generator] failed to set times on "/destination/path/another_directory": Permission denied (13)
rsync: [generator] failed to set permissions on "/destination/path/another_file.txt": Permission denied (13)
rsync: [generator] failed to create directory /destination/path/new_directory: Permission denied (13)
rsync: [receiver] write failed on "/destination/path/some_file.dat": Permission denied (13) (link_dest)
rsync error: some files could not be transferred (code 23) at main.c(1824) [generator=3.2.7]
rsync error: some files could not be transferred (code 23) at main.c(1824) [receiver=3.2.7]

The key indicators here are "Permission denied (13)" messages, often accompanied by rsync error: some files could not be transferred (code 23). These errors pinpoint the exact nature of the problem: the user running rsync does not have the required permissions.

Root Cause Analysis

The "Permission denied (13)" error during an rsync operation almost exclusively points to insufficient file system permissions for the user executing the rsync command, either on the source system (for reading) or, more commonly, on the destination system (for writing).

The underlying reasons can be categorized as:

  1. Destination Write Permissions (Most Common): The user account under which rsync is operating on the destination server (or the user account used to SSH into the destination) does not have the necessary write permissions for the target directory or its contents. This prevents rsync from creating new files/directories, updating existing ones, or changing their attributes.
  2. Source Read Permissions: The user account running rsync on the source server lacks read permissions for files or directories that need to be transferred. This is less common for the "could not be transferred" error, which usually implies an attempt to write failed.
  3. Incorrect Ownership: Files or directories on the destination are owned by a different user or group than the one rsync is trying to use, preventing write access even if general permissions seem open.
  4. Sticky Bit or Immutable Flag: Less common, but specific file system attributes like the sticky bit on directories (chmod +t) or the immutable flag (chattr +i) can prevent deletion or modification, even by root in some cases.
  5. SELinux/AppArmor: On hardened systems, security modules like AppArmor (default on Ubuntu) or SELinux (if installed) might restrict rsync's access to certain paths, overriding standard POSIX permissions.
  6. SSH Key Permissions: If rsync is used over SSH, incorrect permissions on the SSH private key (~/.ssh/id_rsa should be 600) can prevent authentication, leading to connection errors, but not directly "Permission denied" within rsync itself. However, the SSH user's permissions on the remote server are critical.

Understanding the execution context of rsync is crucial. If it's a local transfer, the user is clear. If it's remote over SSH, the permissions on the remote system for the SSH user are what matter.

Step-by-Step Resolution

Follow these steps to diagnose and resolve rsync permission errors. Always start with the destination permissions, as they are the most frequent cause.

1. Identify the User Executing rsync

First, determine which user rsync is operating as on both the source and destination systems (if remote).

  • Local rsync or Source side: The user you are logged in as (whoami).
  • Remote rsync Destination side (via SSH): The user specified in the SSH command (e.g., user@remote). If no user is specified, it defaults to your current local username.

For remote transfers, the permissions on the destination system apply to the remote user you are connecting as. Ensure this user has the necessary privileges on the remote machine.

2. Verify Destination Directory Permissions and Ownership

This is the most common culprit. Connect to your destination server (if remote) and check the permissions and ownership of the target directory.

# On the destination server (or locally if it's a local transfer)
ls -ld /path/to/destination/directory

Example Output:

drwxr-xr-x 3 root root 4096 Aug  5 10:30 /path/to/destination/directory

In this example, the directory /path/to/destination/directory is owned by root:root, and only root has write (w) permissions. If your rsync user is webadmin, it will definitely fail to write here.

3. Correct Destination Ownership and Permissions

Based on the user identified in Step 1, adjust the ownership and permissions on the destination directory.

Be extremely cautious when using chown -R and chmod -R on critical system directories. Incorrect permissions can destabilize your system. Always verify the path.

Option A: Change Ownership to the rsync User

This is often the cleanest solution, giving the rsync user full control over the target directory.

# On the destination server
sudo chown -R your_rsync_user:your_rsync_group /path/to/destination/directory

Replace your_rsync_user and your_rsync_group with the actual user and group. For example, if your rsync user is webadmin:

sudo chown -R webadmin:webadmin /var/www/html/mysite

After changing ownership, verify:

ls -ld /path/to/destination/directory

Option B: Grant Group Write Permissions

If multiple users in a specific group need write access, or you prefer to keep the original owner but allow rsync via group membership:

  1. Ensure the rsync user is a member of the target group.

    # On the destination server
sudo usermod -aG target_group your_rsync_user

    You might need to log out and back in for group changes to take effect.

  2. Set appropriate group write permissions on the directory:

    # On the destination server
sudo chmod -R g+w /path/to/destination/directory

    This gives the group write access. For directories, 775 is common (owner rwx, group rwx, others rx). For files, 664 (owner rw, group rw, others r).

    # Example for web content (owner: webadmin, group: www-data)
sudo chown -R webadmin:www-data /var/www/html/mysite
sudo chmod -R 775 /var/www/html/mysite # For directories
sudo find /var/www/html/mysite -type f -exec chmod 664 {} ; # For files

4. Use rsync's --chown and --chmod Flags (Advanced)

rsync can itself be instructed to set specific ownership and permissions on the destination files as they are transferred. This is powerful when you need to maintain different ownership/permissions on source vs. destination, or when the rsync user doesn't have sudo on the destination but can write, and you want files to land with specific attributes.

The --chown and --chmod flags require the rsync user on the destination to have permissions to change ownership/permissions, typically by running rsync as root (e.g., via sudo or an SSH connection as root).

rsync -avz --chown=webadmin:www-data --chmod=D775,F664 /source/path/ user@remote:/destination/path/
  • --chown=USER:GROUP: Sets the owner and group for all transferred files and directories.
  • --chmod=MODE: Sets file permissions. You can specify different modes for directories (D) and files (F).
    • D775 means directories will have rwxrwxr-x.
    • F664 means files will have rw-rw-r--.

This is incredibly useful for web hosting scenarios where files from a development machine (e.g., owned by devuser:devuser) need to land on the production server owned by webadmin:www-data.

5. Running rsync with sudo (Caution Advised)

If all else fails, or for specific administrative tasks, you can run rsync with sudo. This grants root privileges for the rsync operation.

sudo rsync -avz /source/path/ /destination/path/

For remote destinations, you would connect as root via SSH, or use sudo on the remote end with specific rsync daemon setups.

# Example: Pushing from local to remote as root
rsync -avz /source/path/ root@remote:/destination/path/

# Example: Pulling from remote as root to local via SSH
rsync -avz root@remote:/source/path/ /destination/path/

Running rsync as root or with sudo bypasses standard user permissions checks and can potentially overwrite critical system files if the paths are incorrect. Use this option judiciously and always double-check your source and destination paths.

6. Verify Source Read Permissions

While less common for the specific error, ensure the user running rsync on the source has read access to the files and directories it's trying to transfer.

# On the source server
ls -l /path/to/source/directory

If permissions are too restrictive, adjust them similarly to Step 3, but granting read access (e.g., chmod -R u+r /path/to/source).

7. Check AppArmor/SELinux Logs (Advanced Troubleshooting)

If standard permission fixes don't work, security modules might be interfering.

  • AppArmor (Ubuntu): Check the system logs for AppArmor denials.

    sudo grep "DENIED" /var/log/syslog | grep "apparmor"
sudo dmesg | grep "apparmor"

    If you find denials related to rsync or the paths, you might need to create or modify an AppArmor profile for rsync (advanced topic, usually not necessary for standard rsync operations). A temporary workaround could be to put AppArmor into complain mode for rsync (e.g., sudo aa-complain /usr/bin/rsync) but this is not a permanent solution.

  • SELinux (If installed): Check SELinux audit logs.

    sudo ausearch -c "rsync" --raw | audit2allow -l

    If denials are present, you'll need to create or modify SELinux policies, which is also an advanced task.

By systematically working through these steps, starting with the most common permission issues on the destination, you should be able to resolve "rsync error some files could not be transferred permissions" on your Ubuntu 22.04 LTS systems.