Inaccessible userdata after using chroot-distro

[nickelberg]

I can't be the only one, so it should be pretty self explanatory.
Happened on two my different phones - common features: Xiaomi, rooted, Android 14.
After exiting shell from distro's chroot and then exiting Termux, phone apps don't have access to phone storage.

Examples:

• Gallery not able to display photos
• Files (app) not able to display internal memory files
• Material Files, here I got more informative error message:
  "java8.nio.file.FileSystemException: /storage/emulated/0: opendir: Transport endpoint is not connected"

Edit:
Important to add - a simple reboot fixes this, but it's cumbersome.

[jjkola]

Thanks for the report and the extra information. I did notice your bug report a few days ago. Unfortunately, I have been really busy, so I haven't been able to react to your report.

Just using chroot should not cause this kind of behavior. Also, as chroot-distro uses bind mounts, it should not cause the described behavior.

So, I would like to have more information about the situation so that I can try to reproduce the issue.

First, what distribution did you use? Be as exact as possible.

Second, while using the distribution, what did you do? If you can provide clear steps to reproduce the issue, then all the better.

Third, after exiting the jail, did you just close the Termux, or did you issue some commands?

Also, if you could provide the version of the chroot-distro, that would be helpful.

[nickelberg]

1. Debian 12 and Alpine 3.19
2. Doesn't matter. I can install whole desktop enviroment and vnc server or just do sudo apt update and then quit. It will happen anyway.
3. Steps:
   3.1 chroot-distro:$ exit
   3.2 Termux#: chroot-distro unmount debian
   3.3 Termux#: exit
   3.4 Termux$: exit
   3.5 *app closes*
4. It has happened every time I used chroot-distro. Originally in March 16th version and even in the most recent version v1.1.3.

And most importantly I forgot to add:
I'm not using Magisk, I have KernelSU on both of my phones.
There's a high possibility, this is the bug culprit.

[jjkola]

Unfortunately I don't have any devices with KernelSU so I can't test this. @YasserNull, do you have any devices with KernelSU?

[YasserNull]

No, I don't have any devices with KernelSU.

[roninspin]

chroot-distro unmount <distro> (ubuntu in my case) really unmounts /storage/* for android instead of chroot distro. Maybe chroot_distro_unmount_system_points receives empty distro_path somehow. Why do we touch /storage after all? Isn't /sdcard sufficient?
Btw. I have KernelSU and I use chroot-distro as a standalone script (without installed module).

[defectly]

it's not kernelSU problem i guess, i've been using tmoe with magisk for chroots, and there's same problem with unmount

[jjkola]

I have checked, and distro_path should not be empty. @nickelberg, @roninspin and @defectly, can you run command -v umount and then with the path run ls -l <path returned by command>. I want to check what is providing the umount command. These needs to be run as a root, and I want the output of both commands.

[defectly]

I have checked, and distro_path should not be empty. @nickelberg, @roninspin and @defectly, can you run command -v umount and then with the path run ls -l <path returned by command>. I want to check what is providing the umount command. These needs to be run as a root, and I want the output of both commands.

like this?

[jjkola]

@defectly thanks, that was what I wanted to see

@roninspin Using standalone version of chroot-distro is not a problem, only matter of convenience and preference. If you want, you can run mksh -xv <location of chroot-distro> unmount <distro> after normal login, and redirect the output to a file. The output will tell exactly what commands were run, and with what parameters. If you don't mind would you like to share the output for example through pastebin (or some similar service) if you did run the debug run?

[roninspin]

@roninspin Using standalone version of chroot-distro is not a problem, only matter of convenience and preference. If you want, you can run mksh -xv <location of chroot-distro> unmount <distro> after normal login, and redirect the output to a file. The output will tell exactly what commands were run, and with what parameters. If you don't mind would you like to share the output for example through pastebin (or some similar service) if you did run the debug run?

Here you go
https://pastebin.com/MNdaLxJw

P.S. After unmount:

ls -lR /storage
/storage:
total 3
drwxrwx--- 4 media_rw media_rw 3452 2023-06-26 20:26 emulated
drwxr-xr-x 2 root     root       60 2024-09-21 14:23 self
ls: emulated: Transport endpoint is not connected

/storage/self:
total 0
lrwxrwxrwx 1 root root 19 2024-09-21 14:23 primary -> /storage/emulated/0

[jjkola]

Based on debug log, the script has worked as it should. I'm starting to think that there may be a problem with toybox implementation of umount in this particular situation, or something else which affects umount calls.

@nickelberg, @roninspin and @defectly: Can you provide as much information about your device as possible?

At least device model, android version, firmware version, twrp version (or if you didn't install twrp, then what did you install, or if you didn't install custom recovery at all), kernel version, busybox version (should not matter but does no harm).

Also, can you guys run toybox --version? Also, if you have custom rom, then what rom, and what version? Also, just in case, whether the device has kernelsu or magisk, and what is the version?

One more thing, can you run mount (and redirect the output to file) before distro login, and after exiting the distro but before unmount command, and lastly after unmount, just so that it is easier to see what happens to mounts. And if you could attach the outputs to your reply (one reply per device)?

[defectly]

Based on debug log, the script has worked as it should. I'm starting to think that there may be a problem with toybox implementation of umount in this particular situation, or something else which affects umount calls.

@nickelberg, @roninspin and @defectly: Can you provide as much information about your device as possible?

At least device model, android version, firmware version, twrp version (or if you didn't install twrp, then what did you install, or if you didn't install custom recovery at all), kernel version, busybox version (should not matter but does no harm).

Also, can you guys run toybox --version? Also, if you have custom rom, then what rom, and what version? Also, just in case, whether the device has kernelsu or magisk, and what is the version?

One more thing, can you run mount (and redirect the output to file) before distro login, and after exiting the distro but before unmount command, and lastly after unmount, just so that it is easier to see what happens to mounts. And if you could attach the outputs to your reply (one reply per device)?

Xiaomi Redmi Note 10 Pro
model: M2101K6G
codename: sweet
Android 13 Cherish OS 4.8 (custom)
PitchBlack Recovery Project 4.0
KernelSU version 11872
BusyBox for Android NDK version 1.36.1

mount.txt
mount2.txt
mount3.txt

this problem was even in stock miui rom with tmoe and magisk

[jjkola]

If somebody could also provide their device information if this is working properly, then that may help providing direction to where this bug may lay. Based on the mount data from @defectly, it should work without problems, but clearly it isn't.

I checked toybox change logs from news page and the last time umount command was changed is for version 0.8.0, and the change was to ignore -c parameter. So, most likely toybox is not the cause for the bug unless it is a bug which has been there always/very long time.

P.S. @nickelberg and @roninspin, I would still like to get the device information from you guys, so that we have more data available to help pinpoint where the problem lays.

[roninspin]

Nubia Red Magic 6 (NX669J)
ROM: stock android 12(L)
kernel: 5.4.249 (lots of backports)
TWRP 3.7.0
KernelSU: 11928
toybox: 0.8.4-android
BusyBox for Android NDK version 1.36.1

Turns out that the reason for the problem (at least for me) is the use of umount with -f (forced) for /storage/emulated. Without that parameter no problems at all.
So, @jjkola, I think you should omit it, at least for /storage/*.

[jjkola]

@roninspin Thanks, good catch. We will have to investigate this but it sounds like something has changed on kernel side which makes it unusable on newer kernels (my device is Asus Zenpad 10 (Z301M) with 3.18.35 kernel, and it works). Bind mounts should never affect their originator mounts but clearly this has been broken at some point.

@YasserNull Do you happen to remember why -f flag has been added? I tried digging through the version control but umount -lf <path> seems to be even in the first uploaded version of the file.

[nickelberg]

Sorry for not much response from me, I'm kinda busy irl lately.

---

@jjkola

Phone 1:

• Phone: Xiaomi Mi 9T Pro (codename raphael)
• ROM: Android 14 - LineageOS 21 (Unofficial build)
• Kernel: 4.14.350
• Recovery: OrangeFox R11.1_4 Stable
• KernelSU: 11872
• Toybox: 0.8.10-android
• BusyBox: 1.36.1

Phone 2:

• Phone: POCO F4 GT (codename ingres)
• ROM: Android 14 - HyperOS 1.0.4.0.ULJCNXM (xiaomi.eu)
• Kernel: 5.10.192
• Recovery: OrangeFox R12.1_1 Unofficial
• KernelSU: 11928
• Toybox: 0.8.9-android
• BusyBox: 1.36.1

[YasserNull]

@jjkola In fact, I don't remember, but what I do remember is that I used ChatGPT to learn how to use this command.

[jjkola]

I did a test on my raspi device where I did multiple successive bind mounts, and forced unmount (-lf) worked properly with kernel 6.6.47. I did the test with normal mount/umount as well as with toybox (0.8.9) mount/umount. I did use loopback device as the source so that is not the same as with block devices.

[roninspin]

Anyway, -f shouldn't be used all the time (by default).

[jjkola]

Fix released.

[defectly]

Fix released.

so how do i shutdown it?

[jjkola]

I'll try to add more output to error message to make it easier to pinpoint the problem. Most likely I will have time for that next weekend.

[jjkola]

In the mean time, you can try following:
mount | grep <mount_point_path>
losetup | grep <mount_point_path>
lsof | grep <mount_point_path>

If those don't help (and there is no running processes) then you will have to check for anonymous inodes and inotify watchers.

[defectly]

In the mean time, you can try following: mount | grep <mount_point_path> losetup | grep <mount_point_path> lsof | grep <mount_point_path>

If those don't help (and there is no running processes) then you will have to check for anonymous inodes and inotify watchers.

can it be automatic? tmoe has feature to kill chroot, and it also kills chroot if you use unmount in it

[jjkola]

Sure, it can be added. But it can't be default action as it can leave the jail in inconsistent state as it will not bring it down in managed/consistent way. At least, I would prefer bringing my stuff down in a way that it will not cause problems for me in the future.

Also, just to be clear the unmount command just unmounts the known system mount points, it does nothing more, nothing less.