[3.5.0] rsync: [Receiver] change_dir#1 "/.../" failed: Too many levels of symbolic links (40)

[jb2170]

Upgrading from rsync-3.4.4-1 to rsync-3.5.0-1 on Arch has broken rsync for me. I backup my computer using rsync from my root partition to an external drive.

I get

sending incremental file list
rsync: [Receiver] change_dir#1 "/home/jb2170/Mount/WD14TB-Grey/Mount/Backups/WD/Master/" failed: Too many levels of symbolic links (40)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(768) [Receiver=3.5.0-g471e17dc]

from running my Makefile target $ make backup in /home/jb2170/Mount/WD14TB-Grey/Makefile

.PHONY: backup
backup:
        sudo rsync -vaAHb --del --delete-excluded \
        --backup-dir "../Old/${TIMESTAMP}/" \
        --exclude-from ${RSYNCIGNORE} \
        / \
        ${BACKUP_DIR_BASE}/Master/
        sudo chmod o+rX "${BACKUP_DIR_BASE}/Old/${TIMESTAMP}/"

which for example expands to

sudo rsync -vaAHb --del --delete-excluded --backup-dir "../Old/2026-08-28T20:39:32+01:00/" --exclude-from rsyncignore.txt / Mount/Backups/WD/Master/

which also fails on the command line (so it's not a Makefile issue), and where /home/jb2170/Mount (which has no symlinks in it) looks like the following

.
├── run -> /run/media/jb2170/
└── WD14TB-Grey
    ├── key.bin
    ├── Makefile
    ├── Mount -> ../run/e2e96953-26e1-4d5d-8100-cb082b14985e/
    └── rsyncignore.txt

and /home/jb2170/Mount/WD14TB-Grey/Mount, real path /run/media/jb2170/e2e96953-26e1-4d5d-8100-cb082b14985e, looks like the following

.
└── Backups
    └── WD
        ├── Master
        │   ├── etc
        │   ├── home
        │   ├── public
        │   └── var
        └── Old

[seks99x]

This is most likely because of the ownership of the symlink. The symlink Mount needs to be owned by root or by the same UID running the process (This is called trusted UID to avoid malicious users from redirecting the transfer out of the tree).
Can you recheck the ownership of the symlink?

[jb2170]

Everything is owned by jb2170 (my normal user account) except /run/media/jb2170/ which is owned by root with perms drwxr-x---+, with $ getfacl /run/media/jb2170/ showing user:jb2170:r-x. This has never been an issue before, and shouldn't start being one now, and rsync 3.4.4 (which I've downgraded to) still works as normal.

[seks99x]

This is not an issue, this was the fix for CVE-2026-53796. You cant be using rsync with sudo and the Mount symlink be owned by jb2170 so you have two choices either setting the Mount symlink to be owned by root or use --insecure-links option with the transfer. Put in my mind if you used --insecure-links option, your machine is vulnerable to LPE because any other local user on the machine can plant a symlink to arbitrary location and redirect the transfer.

[jb2170]

Adding --insecure-links works for me, thanks. It's a local computer that I trust.

Or alternatively changing Mount/Backups/WD/Master/ to /run/media/jb2170/e2e96953-26e1-4d5d-8100-cb082b14985e/Backups/WD/Master/ to avoid the symlink.

I think I'll stick with the former to restore the old behaviour.

Maybe the new error message could be made a bit more intuitive?

---

wrt fixing CVE-2026-53796, I've done a bit of reading on the CVE but I don't fully understand how it's a race condition issue? Couldn't a malicious user change a symlink in the first place, before rsync runs, like with

lrwxrwxrwx 1 jb2170 jb2170  1 Aug 29 01:30 a -> b
lrwxrwxrwx 1 sneed  sneed   1 Aug 29 01:30 b -> c
drwxrwx--- 2 jb2170 jb2170 40 Aug 29 01:29 c
drwxrwx--- 2 jb2170 jb2170 60 Aug 29 01:29 src

user sneed could at any time change b to point elsewhere, so if jb2170 later tries $ rsync -vaH ./src/ ./a/ then the files would be redirected elsewhere? We get the rsync: [Receiver] change_dir#1 "/tmp/blah/./a/" failed: Too many levels of symbolic links (40) error in 3.5.0 and not in 3.4.1 with this setup as expected, but isn't it really just up to the end user to choose whether they trust the trees in the first place, and if the trees change whilst being traversed then welp ¯\_(ツ)_/¯?

At any rate the hardening sounds like a decent idea. It reminds me of openssh having strict requirements for ownership of authorized_keys and its parents.

---

Also apologies for my rude tone in

This has never been an issue before, and shouldn't start being one now

I was expecting this to be an AI-generated code issue, not the result of intentional security hardening and CVE fixing 😅 The error message isn't obvious.

[seks99x]

No worries! Actually the root cause is the same for both TOCTOU or static plant symlink follow, using syscalls that rely on the path without fd pinning or missing O_NOFOLLOW flag. Our defense against these symlink attacks actually comes down to using the ⁠O_NOFOLLOW⁠ flag along with ⁠*at()⁠ syscalls. Whenever we hit a symlink (or a chain of them), we recursively read the links instead of following them. We check two main things: whether the link is owned by a trusted UID, and (if it's a daemon or root-confined process) whether the final destination escapes the designated tree .We essentially calculate the real path manually so we never blindly follow an untrusted link. If it didn’t pass the two checks we never follow the link , we resolve it and go to the real path.

Regarding AI, its a bit unfair to underestimate the quality of the code because its written with AI. Even if AI is included, no new changes is submitted without human eyes review it. When bugs/regressions do pop up, it's usually because of how complex the codebase is and how hard it is to lock down security without breaking people's custom setups.

[steadytao]

The hardening behaviour is intentional but the current ELOOP message gives the operator no useful explanation. We should report that an untrusted symlink component was rejected and mention --insecure-links as an explicit compatibility escape hatch with the associated local privilege-escalation risk.

[peabee]

Slackware64 Current updated to rsync-3.5.0 on 13 August.
With rsync-3.5.0 I get the error:
rsync: [sender] opendir "/mnt/home/My_Documents" failed: Too many levels of symbolic links (40)

There are no symlinks in the directory.

If I revert to rsync-3.4.4 from the Slackware Archive the error does not appear.

[seks99x]

Could you please clarify more about the directory structure and ownerships? show me the full command you ran and the tree structure of the sender

[peabee]

Hi
This is Puppy Linux so the vast majority of files belong to root:root. A very small number belong to spot:spot
The command is embedded inside an app and I only have access to the log it produces.
I can send you the tree privately but wouldn't want to post it here.