3.5.0 fails under termux

rsync: [Receiver] change_dir#1 "/sdcard/" failed: Permission denied (13)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(768) [Receiver=3.5.0]
rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(849) [sender=3.2.7]

fix is downgrade to 3.4.4

curl --parallel --keepalive-time 5 --location --ipv4 --output /sdcard/rsync/rsync_3.4.4_aarch64.deb --url https://termux.librehat.com/apt/termux-main/pool/main/r/rsync/rsync_3.4.4_aarch64.deb
dpkg -i /sdcard/rsync/rsync_3.4.4_aarch64.deb

Yeah, I know what is causing this. Last regression I am addressing before I get some more sleep and will return in the afternoon 😭

i can't believe this happened again

i can't believe this happened again

Any ideas on how we can improve our Termux coverage? I do not use Termux myself nor do I believe any active contributors do. Lets please be productive rather than complaining while people are trying to triage release-week problems. A test case, CI setup or help maintaining that platform would be useful.

i don't know how. maybe termux devs have ideas or they are willing to test it

since it happened again, they probably didn't test it. or tested in different way

if somebody have reminded me to test it, it would have not happened. or any other termux users

but i guess it wouldn't be hard to setup emulator

tho, rsync is used everywhere and i can't even imagine all platforms to test on

i would guess manual user test maybe? would be best

how do i know

the "i can't believe this happened again" was purely because i assumed that it's now tested and will not happ4n

... will not happen again

nothing else

I can confirm this on Termux with rsync 3.5.0.

The destination itself is accessible from the same SSH session and security context. For example, this succeeds:

cd /storage/emulated/0/Documents/example
touch .test
rm .test

However, rsync 3.5.0 fails with:

rsync: [Receiver] change_dir#1 "/storage/emulated/0/Documents/example" failed: Permission denied (13)

I also tested the direct /storage/emulated/0/... path instead of Termux's ~/storage/shared symlink, with the same result, so this does not appear to be caused by the storage/shared symlink itself.

A diagnostic wrapper confirmed that the shell can cd to the exact destination immediately before exec rsync, while rsync then fails on the same path.

strace identifies the failure more precisely:

newfstatat(AT_FDCWD, "/storage/emulated/0/Documents/example",
           {st_mode=S_IFDIR|S_ISGID|0770, ...}, 0) = 0

openat(AT_FDCWD, "/", O_RDONLY|O_CLOEXEC|O_DIRECTORY)
    = -1 EACCES (Permission denied)

So the destination path is successfully resolved/stat'ed. The failure happens when the new 3.5.0 hardened path traversal tries to open / with O_RDONLY|O_DIRECTORY.

This seems consistent with Android/Termux allowing traversal through / to known paths while not allowing an untrusted app process to open the root directory for reading.

PR #1052 (O_PATH for directory traversal) appears to address exactly this case. The strace above also suggests that the issue is specifically the requirement to O_RDONLY-open the traversal anchor rather than an actual lack of access to the destination.

@ketas

@ketas Termux was not tested because none of the active contributors use it. We cannot feasibly personally remind users of every platform before each release. If you are willing to test release candidates on Termux, that would genuinely help prevent this happening again. Otherwise, please do not assume coverage exists and then complain when it does not; as you stated, I cannot imagine the amount of platforms we would have to test on to cover every possible use-case.

unsure why everyone seems like as if attacked here?

but yeah, i knew new rsync was coming out but i assumed there will be no issues anymore

altho last one was rare older android issue

i think rsync releases are still quite rare that i can test them manually

or i assume there are more users other than me, i bet we can find enough testers

from what i get, this is another overagressive security patch

anyway, i'm interested in testing them so by the time the release comes i don't need to downgrade :)

@steadytao

@steadytao, feel free to use my PR #920 as a basis for running the test suite under Android if there is interest within the project in doing that. As I got no feedback after several requests I assumed there wasn't.

Any ideas on how we can improve our Termux coverage? I do not use Termux myself nor do I believe any active contributors do. Lets please be productive rather than complaining while people are trying to triage release-week problems. A test case, CI setup or help maintaining that platform would be useful.

Hello, the KVM-based solution in #920 is one option, which can have high accuracy, but requires a lot of setup and takes a long time to spin up.

There is also another option which is termux-docker, which can be run in the docker command directly in GitHub Actions regular steps, but can also, with some workarounds and setup, be used with the GitHub Actions container: directive to have every command in each step in the job run inside the Termux. My example for that is here:

https://github.com/robertkirkman/termux-on-gha/blob/master/.github/workflows/build-and-test.yml

termux-docker has somewhat lower accuracy of bare metal Android's behavior than regular KVM-based Android AVD emulators, but it is able to reproduce at least this specific recent problem with rsync.

Example of some basic commands and current output in termux-docker as an introduction:

~ $ mkdir test_dir
~ $ rsync a.out test_dir/
rsync: [Receiver] change_dir#1 "/data/data/com.termux/files/home/test_dir/" failed: Permission denied (13)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(768) [Receiver=3.5.0]
~ $ pwd
/data/data/com.termux/files/home
~ $ termux-info
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
/data/data/com.termux/files/usr/bin/getprop: 3: exec: /system/bin/getprop: not found
Termux Variables:
unsupported
Packages CPU architecture:
i686
Subscribed repositories:
# sources.list
deb https://packages-cf.termux.dev/apt/termux-main stable main
# x11-repo (sources.list.d/x11.list)
deb https://packages-cf.termux.dev/apt/termux-x11 x11 main
Updatable packages:
All packages up to date
termux-tools version:
1.45.0
Android version:

Kernel build information:
Linux acc8d5b195b6 6.18.32-p2-gentoo-dist #1 SMP PREEMPT_DYNAMIC Mon May 25 02:11:07 CDT 2026 i686 Android
Device manufacturer:

Device model:

Supported ABIs:
SUPPORTED_ABIS: 
SUPPORTED_32_BIT_ABIS: 
SUPPORTED_64_BIT_ABIS: 
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec-ld-preload.so
~ $

showing it reproducing this issue, showing its home folder path, and showing its termux-info output; termux-docker doesn't support the getprop command, so that is an example of one of the typical ways it differs from/is inaccurate to regular bare metal Android.

since it happened again, they probably didn't test it. or tested in different way

if somebody have reminded me to test it, it would have not happened. or any other termux users

in termux, updates of rsync are directly deployed (with an automated script and no maintainer intervention) to all users without runtime testing, only build testing. in Termux, it builds -> it ships.

clearly that has tradeoffs, but that is not my decision! It is something almost all of Termux has done for years before I started contributing to Termux.

i wonder if different androids need testing too, here

i think of android as massive shitshow that nobody wants to dev on or use but everybody has to endure. like 11th plague of egypt. because for some reason it's in nearly every phone. but it's about as hard and difficult as it can get. never got it

i wonder what does it take to automatically test rsync for some common platforms? hopefully vm's would be enough

unless i see it wrong, it would run overnight on a pc out of trash with less than a single sandwich amount of power cost? i mean it's 2026? no need to book computer time in university anymore. also why limit ourselves to some "github actions"

of course, if first tester is a person who upgrades their rsync in termux, then i'm not surprised if this becomes a regular thing. the user is a tester then. that probably pisses user off since (s)he expected it being tested since was published. because who publishes untested stuff? user also thinks that rsync is also widely known thing and therefore must certainly have been tested

to be honest, this isn't the first time when i run something and i'm like hey there's a bug right there. then i report it and dev agrees that there's indeed a bug. it doesn't seem to matter how big the project is or if it's paid or not

how to fix things like this?

Thank you all for the ideas. Working out a scope for a CI rework, you can track that here - #1059

Otherwise this is resolved, I will merge relatively shortly**
Thank you all for your time

ok

my mistake was to trust it being tested now

here's files i use to backup my phones, should any devs have any around and wish to dogfood:

http://ketas.si.pri.ee/misc/termux-rsync-backup/

or

job-add.sh

#!/data/data/com.termux/files/usr/bin/sh


termux-job-scheduler \
-s /data/data/com.termux/files/home/periodic.sh \
--job-id 100 --period-ms 3600000 \
--battery-not-low false --persisted true

job-del.sh

#!/data/data/com.termux/files/usr/bin/sh


termux-job-scheduler --cancel --job-id 100

job-list.sh

#!/data/data/com.termux/files/usr/bin/sh


termux-job-scheduler -p

periodic.sh

#!/data/data/com.termux/files/usr/bin/sh


./rsync-backup-termux.sh

./rsync-backup-storage.sh

rsync-backup-storage.sh

#!/data/data/com.termux/files/usr/bin/sh


device="`cat /data/data/com.termux/files/home/device`"


if [ ! "$device" ]
then
	termux-notification -c "[$0] no device"
	
	
	exit 1
fi


flock -n -E 0 \
/data/data/com.termux/files/home/rsync.lock \
rsync -vhhhirlt --progress --no-perms \
--chmod=D755,F644 --exclude=/Android/data \
--exclude=/Android/obb --delete --delete-excluded \
-e 'ssh -i'\
" /data/data/com.termux/files/home/.ssh/$device" \
/storage/emulated/0/ \
"$device@$device.connection-targets.rsync.si.pri.ee"\
":data/$device/"


exit_code="$?"


if [ "$exit_code" -ne 0 ]
then
	termux-notification \
	-c "[$0] rsync exit code = $exit_code"
fi

rsync-backup-termux.sh

#!/data/data/com.termux/files/usr/bin/sh


flock -n -E 0 \
/data/data/com.termux/files/home/rsync.lock \
rsync -vhhhirt --info=nonreg0 --progress --no-perms \
--chmod=D755,F644 '--exclude=*::*' \
'--exclude=/files/usr/lib/perl?/*/?od' \
'--exclude=/files/usr/include/linux/netfilter*' \
--exclude=/files/usr/var/run/cron.reboot \
--exclude=/files/usr/share/LICENSES \
--delete --delete-excluded \
/data/data/com.termux/ \
/storage/emulated/0/termux/data-data-com.termux/


exit_code="$?"


if [ "$exit_code" -ne 0 ]
then
	termux-notification \
	-c "[$0] rsync exit code = $exit_code"
fi

Thank you very much!

Fix back ported in fix(main/rsync): backport upstream directory traversal fix termux/termux-packages#31120

Fix back ported in fix(main/rsync): backport upstream directory traversal fix termux/termux-packages#31120

Thank you ❤️

I found a related remaining case in the separate held-directory-fd path. It is tracked in #1064, with a proposed fix in #1065. #1052 fixed the original path, but some operations still require directory read permission where search permission should be sufficient.

ci: pin Debian/Fedora test images below rsync 3.5.0

fork: seed from gokrazy/rsync with receiver-side --partial (#1)

Navigation Menu

Repository navigation

3.5.0 fails under termux #1050

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

3.5.0 fails under termux #1050

Description

Activity

steadytao commented on Aug 13, 2026

ketas commented on Aug 14, 2026

steadytao commented on Aug 14, 2026

ketas commented on Aug 14, 2026

ketas commented on Aug 14, 2026

imagebuilder1837 commented on Aug 15, 2026

steadytao commented on Aug 15, 2026

ketas commented on Aug 15, 2026

ribbons commented on Aug 15, 2026

robertkirkman commented on Aug 15, 2026

robertkirkman commented on Aug 15, 2026

robertkirkman commented on Aug 15, 2026

ketas commented on Aug 15, 2026

steadytao commented on Aug 16, 2026

steadytao commented on Aug 16, 2026

ketas commented on Aug 17, 2026

steadytao commented on Aug 17, 2026

TomJo2000 commented on Aug 18, 2026

steadytao commented on Aug 18, 2026

FusionPow commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions