rsync 3.5.0 regression on FreeBSD: non-root receiver gets EACCES on change_dir#1

[freegateway]

Summary

After upgrading from rsync 3.4.4 to 3.5.0 on a FreeBSD system, rsync pushes over SSH fail when the remote receiver runs as a non-root user:

rsync: [Receiver] change_dir#1 "/var/www/site/public_html/test/" failed: Permission denied (13)

rsync successfully creates the destination directory, but then fails when attempting to enter it.

Downgrading to rsync 3.4.4 fixes the problem with no other changes.

I've reproduced the problem on two separate FreeBSD 15.1-STABLE systems, one a jail and one a normal host.

Systems

Server 1 (FreeBSD jail):

FreeBSD 15.1-STABLE #0 stable/15-bd0449aab239-dirty:
Sat Aug 29 14:07:37 UTC 2026
rsync 3.5.0, protocol version 32

Server 2 (FreeBSD host, not a jail):

FreeBSD 15.1-STABLE #0 stable/15-3701716fdc45-dirty:
Tue Jul 28 02:04:42 UTC 2026
rsync 3.5.0, protocol version 32

Both hosts use custom FreeBSD kernels.

Tests

On Server 1 the receiver runs as:

uid=2000(webmaster) gid=80(www) groups=80(www)

The destination directory created by rsync is owned by webmaster:www and has mode 0755. Its NFSv4 ACL grants the owner read/write/execute access.

All destination path components from /var/www/site downward are owned by webmaster, and none are symbolic links.

I performed the following tests:

rsync 3.4.4, non-root receiver                       WORKS
rsync 3.5.0, non-root receiver                       FAILS: EACCES at change_dir#1
rsync 3.5.0, FreeBSD-specific FLAGS patch disabled   FAILS: same error
rsync 3.5.0, receiver running as root                WORKS
rsync 3.5.0, non-root receiver in jail               FAILS
rsync 3.5.0, non-root receiver, no jail              FAILS

As the non-root user, both interactive and non-interactive SSH commands can cd into the destination and create files/directories there without error.

Thus:

• the filesystem permissions allow the operation;
• the problem is not specific to FreeBSD jails;
• the problem persists with the FreeBSD-specific FLAGS patch disabled;
• changing only rsync from 3.5.0 to 3.4.4 fixes it;
• running the 3.5.0 receiver as root also avoids it.

Example command

The failing rsync push command is approximately:

rsync \
    --verbose \
    --itemize-changes \
    --human-readable \
    --archive \
    --hard-links \
    --acls \
    --xattrs \
    --new-compress \
    --delete \
    --partial \
    --numeric-ids \
    -e /usr/local/bin/ssh \
    -i /home/user/.ssh/id_webmaster@www.example.com \
    /tmp/test/ \
    webmaster@www.example.com:/var/www/site/public_html/test/

Both sender and receiver are rsync 3.5.0.

Conclusion

This appears to be an upstream rsync 3.5.0 regression affecting non-root receivers on FreeBSD.

Given the change_dir#1 failure and the fact that 3.4.4 works, the new destination-path resolution/security code introduced in 3.5.0 may be relevant, but I have not established that as the cause.

I cannot currently provide a ktrace because I intentionally built the primary server's custom kernel without options KTRACE.

[steadytao]

This seems genuine but EACCES does not identify which part of the secure directory walk failed. Could you please test the same minimal transfer once with --insecure-links? Do not retain that as a permanent workaround unless every local path component is trusted. If it succeeds, that isolates the new secure change_dir() path.

Please also provide ls -led and getfacl output for every component from / through the destination, including /var and /var/www. If truss is available, a trace of the remote receiver identifying whether openat() or fchdir() returns EACCES would settle the implementation question.

FreeBSD has O_SEARCH specifically for directory traversal while directory_traverse_flags() currently prefers O_PATH when available. We should consider preferring O_SEARCH on BSD only if the trace confirms that the descriptor mode is the failing boundary.

[freegateway]

I did one additional test.

I cloned the current rsync master branch from GitHub, built it, and installed it on the remote FreeBSD server. I then repeated the same transfer using the non-root webmaster user.

The transfer succeeded.

So the behavior is:

rsync 3.4.4          WORKS
rsync 3.5.0          FAILS: EACCES at change_dir#1
current master       WORKS

It therefore appears that this regression is specific to the 3.5.0 release and has already been fixed in the current upstream code.