Sender-side ELOOP after upgrading to 3.5.0

[steadytao]

@peabee reported this in #1067 after upgrading from 3.4.4 to 3.5.0:

rsync: [sender] opendir "/mnt/home/My_Documents" failed: Too many levels of symbolic links (40)

Reverting to 3.4.4 reportedly fixes the transfer. The system is Puppy Linux using Slackware64 Current packages. It is not yet clear whether the failure depends on that setup. The command runs inside an application and has not been provided. Peabee says there are no symlinks inside the directory and most files are root:root with a few owned by spot:spot.

I am opening this separately because #1067 was closed after addressing @jb2170’s receiver-side error. #1074 added a diagnostic for an untrusted symlink rejected by ona_open(). It did not change the sender’s directory scan. In 3.5.0, that scan can use secure_opendir(), whose resolver rejects absolute symlink targets or relative targets that escape its anchor. That could explain this report. It has not been confirmed; having no symlinks inside the directory does not rule it out.

I will investigate the failing path and compare it against 3.4.4 before proposing a fix. Any change needs to retain the protection against symlinks redirecting a transfer outside its permitted root.

@peabee, could you provide the application name and the output of namei -l /mnt/home/My_Documents ? There is no need to post the whole directory tree.

[peabee]

@peabee reported this in #1067 after upgrading from 3.4.4 to 3.5.0:

rsync: [sender] opendir "/mnt/home/My_Documents" failed: Too many levels of symbolic links (40)

Reverting to 3.4.4 reportedly fixes the transfer. The system is Puppy Linux using Slackware64 Current packages. It is not yet clear whether the failure depends on that setup. The command runs inside an application and has not been provided. Peabee says there are no symlinks inside the directory and most files are root:root with a few owned by spot:spot.

I am opening this separately because #1067 was closed after addressing @jb2170’s receiver-side error. #1074 added a diagnostic for an untrusted symlink rejected by ona_open(). It did not change the sender’s directory scan. In 3.5.0, that scan can use secure_opendir(), whose resolver rejects absolute symlink targets or relative targets that escape its anchor. That could explain this report. It has not been confirmed; having no symlinks inside the directory does not rule it out.

I will investigate the failing path and compare it against 3.4.4 before proposing a fix. Any change needs to retain the protection against symlinks redirecting a transfer outside its permitted root.

@peabee, could you provide the application name and the output of namei -l /mnt/home/My_Documents ? There is no need to post the whole directory tree.

Apparently the problem is because /mnt/home is a symlink (which is probably Puppy Linux specific):

# ls -ld /mnt /mnt/home /mnt/home/My_Documents
drwxr-xr-x 24 root root 4096 Sep 14  2026 /mnt
lrwxrwxrwx  1 root root   20 Sep 14  2026 /mnt/home -> /initrd/mnt/dev_save
drwxr-xr-x 17 root root 4096 Sep 13 06:50 /mnt/home/My_Documents

If I change the sender to: /initrd/mnt/dev_save/My_Documents then the backup with rsync-3.5.0 completes correctly.

The /mnt/home symlink has never been a problem in the past so wondering why it has become a problem in 3.5.0 compared to 3.4.4?

# namei /mnt/home/My_Documents/ f: /mnt/home/My_Documents/ d / d mnt l home -> /initrd/mnt/dev_save d / d initrd d mnt d dev_save d My_Documents

[steadytao]

Introduced while fixing CVE-2026-53801. I have likely found what the issue is, I truly hate symlinks 😢 Might not be able to fix tonight but will be done within the next 24 hours.

[steadytao]

Also, not really specific to Puppy but perhaps by default? Either way I will let you know once the fix is ready and ask you to test; thanks for reporting.