TL;DR: SUSFS for KernelSU can make modules appear to vanish after boot on Android 17 when their mounts do not propagate into the namespace used by zygote_next or the affected app. Confirm the mismatch with mountinfo, then use compatible kernel, manager and module builds; there is no verified universal “dummy zygote” fix.
By the PrivacyPortal team
Last updated July 2026
When a KernelSU module is enabled but stops working after Android 17 finishes booting, the module itself may be healthy. The usual cause is that its files were mounted in one Linux mount namespace while the app was launched from another. This is especially relevant to late-mounted modules, encrypted storage and SUSFS fast_umount configurations. Back up everything before changing the kernel or root stack: unlocking the bootloader wipes user data, and a bad kernel or incompatible module can cause a bootloop. Rooting may also affect warranty support, over-the-air updates, device security, Play Integrity and banking apps. No configuration can be guaranteed to satisfy a particular app’s checks.
Image caption: A KernelSU module can be mounted globally yet remain invisible inside the namespace inherited by an Android app.
What is going wrong on Android 17?
Android isolates processes with Linux mount namespaces. Each namespace has its own view of mounted filesystems, so a mount visible to one process is not necessarily visible to another. Android applications normally inherit their initial view from a zygote process, the system service that starts app processes.
Android 17 adds the Rust-based zygote_next. Google’s public reporting indicates that zygote_next can inherit the global mount namespace, changing assumptions made by root and hiding tools. A module mounted after a clean namespace was created may not automatically appear there. Conversely, a mount left in the global namespace may become visible where it was not intended.
Google Issue 528961873 identifies Android 17 zygote_next mount-namespace exposure as a platform-level compatibility concern.
This is a propagation problem rather than proof that KernelSU failed to load the module. The manager can report the module as enabled because its scripts ran successfully, even while an app receives a namespace that lacks the module’s mounts.
Read the public Android 17 zygote_next issue alongside the official KernelSU module documentation. Both are more dependable than copying a device-specific shell snippet from a chat archive.
Why SUSFS fast_umount changes module visibility
SUSFS is a kernel patch used with KernelSU-compatible root implementations to conceal selected filesystem artefacts and manage mount visibility. Its fast_umount design aims to move selected applications into a clean mount namespace efficiently. This is materially different from merely hiding a filename in userspace.
A clean namespace is a snapshot, not a permanently synchronised mirror. If KernelSU creates a module mount after that namespace exists, the later event may not propagate into it. Modules mounted after boot completion or shared-storage decryption are the most likely to expose this timing problem.
Community proposals describe entering both a “real zygote” namespace and a “dummy zygote_next” namespace before creating late mounts. As of 21 July 2026, that procedure is not documented as a universal fix in the authoritative Android, KernelSU or SUSFS sources. Process layout, propagation flags and SELinux policy differ between builds, so blindly copying an nsenter command can produce an insecure configuration or another boot failure.
SUSFS 1.5.9 was community-reported with KernelSU Next on some Pixel 8 Android 15 and 16 builds; that pairing does not establish Android 17 compatibility.
Is it a namespace problem or a broken module?
| Observation | Most likely cause | Best next check |
|---|---|---|
| Module is disabled in the manager | Installation, metadata or compatibility failure | Read the KernelSU module log |
| Module works immediately after boot but fails later | Late namespace transition or service restart | Compare mountinfo before and after failure |
| Module works in a root shell but not in an app | Different mount namespaces | Compare the shell, zygote and app process |
| All modules disappear for apps without root | KernelSU “Umount modules” behaviour | Temporarily test the manager setting |
| Failure began after adding a second module | Conflict, boot-stage ordering or replaced files | Remove the newest module and retest |
| Device cannot finish booting | Kernel or module incompatibility | Use recovery or the documented rescue method |
KernelSU’s module-unmount setting is easy to mistake for a fault. It deliberately prevents apps without root permission from seeing module mounts. That is useful for reducing exposure, but it is incompatible with modules whose purpose is to alter files for those same apps. Decide which behaviour you require before changing SUSFS.
Prerequisites and safety checks
- A complete backup stored away from the phone, including authenticator recovery codes and encryption keys.
- An unlocked bootloader. Unlocking normally performs a factory reset, so complete the backup first.
- The exact factory boot images for the installed device model and build number.
- A known working recovery route, fastboot connection and USB cable.
- A kernel explicitly built for that firmware with the required KernelSU and SUSFS patches.
- A manager compatible with that kernel, such as the maintainer-specified KernelSU, KernelSU Next or SukiSU Ultra build.
- The matching susfs4ksu userspace module when required by the kernel integration.
- Android SDK Platform Tools on the computer and working adb and fastboot access.
Do not mix a kernel, manager and SUSFS module simply because their version numbers look recent. Kernel interfaces can change between forks and releases. The device maintainer’s tested combination takes priority over a generic recommendation.
Android’s bootloader documentation states that changing lock state erases user data to prevent unauthorised access.
The files named in the automatically appended “Modules, apps & files to try” section should still be checked against their official release notes and signatures. Never install a module received from an unknown Telegram account, shortened link or repackaged archive. A malicious module can execute service.sh during installation and obtain root access before the next reboot.
How to install and diagnose SUSFS for KernelSU safely
- Record the baseline. Note the device model, Android build number, kernel string, root manager version, SUSFS version and every enabled module. Take screenshots or export logs before altering anything.
- Back up and prove recovery access. Confirm that the computer detects the device with adb devices while Android is running and fastboot devices in the bootloader. Keep the exact stock images locally. Do not proceed if recovery depends on files stored only on the phone.
- Confirm the supported stack. Use a kernel release that explicitly names your model, firmware and Android 17 support. Check whether its maintainer requires KernelSU, KernelSU Next or SukiSU Ultra and which susfs4ksu release accompanies it. Do not reuse the Android 15 or 16 Pixel 8 combination solely because SUSFS 1.5.9 was reported working there.
- Remove variables before flashing. Disable third-party root-hiding, integrity and filesystem-overlay modules. Reboot once and verify that the base KernelSU installation remains stable. Keep only the minimum components needed for the test.
- Install the compatible kernel using its official procedure. Some devices flash a boot image, while others use vendor_boot, init_boot or a recovery package. Follow the device maintainer’s partition-specific instructions exactly. Flashing a generic image to the wrong partition can brick the device.
- Boot and verify the manager. Open the matching KernelSU-family manager and confirm that kernel support is detected. Do not install further modules if the manager reports an unsupported kernel or an unexpected version.
- Install susfs4ksu when the kernel requires it. Select the verified archive from the manager’s module installation screen, read the complete installer output and reboot. Use the specific file identified in the appended files section, not a similarly named re-upload.
- Install one functional module. Add only the module whose missing mounts you want to test. Reboot, unlock the device and wait until encrypted shared storage is available. This separates a namespace problem from a conflict between several modules.
- Choose a unique mount marker. Find a distinctive directory or filename created by the functional module from its documentation or installation log. Substitute that text for MODULE_MARKER in the diagnostic commands; do not assume every module mounts under the same path.
- Check the zygote namespaces. Run adb shell su -c 'pidof zygote64 zygote zygote_next'. For each returned process ID, run adb shell su -c 'grep MODULE_MARKER /proc/PROCESS_ID/mountinfo'. An empty result means that namespace cannot see the selected mount marker.
- Check the affected application. Obtain its process ID with adb shell pidof package.name, replacing the package name with the real identifier. Then run adb shell su -c 'grep MODULE_MARKER /proc/APP_PID/mountinfo'. Restart the app before testing so it is spawned under the current zygote state.
- Perform a controlled fast_umount comparison. Change only the documented SUSFS fast_umount or KernelSU “Umount modules” setting, reboot and repeat the checks. If the marker reappears in the affected app, the result supports a namespace-routing diagnosis. It does not prove that root detection has been defeated.
- Apply the supported remedy. Update to a module release that explicitly handles Android 17 late mounts, or use the kernel maintainer’s documented namespace fix. If no supported build exists, leave fast_umount disabled for that module or remove the module. Do not improvise persistent nsenter scripts against changing zygote process IDs.
- Verify stability. Reboot twice, unlock shared storage, restart the target app and compare mountinfo again. Test calls, alarms, camera, Wi-Fi and encryption before considering the setup stable. Retain the logs and known-good stock image.
Image caption: Comparing proc mountinfo for zygote_next and the affected app reveals whether both processes inherited the module mount.
How to interpret the mountinfo results
If the marker appears in the global or root-shell view but not in zygote_next, the mount was probably created after the clean namespace or was deliberately excluded. The proper solution belongs in the compatible module, SUSFS userspace component or kernel integration—not in a one-off command run after every boot.
If zygote_next sees the marker but the app does not, confirm that the process ID is current. Force-stopping and reopening the app may create a new process under a different zygote or isolated service. Also check whether the app uses a secondary process declared in its manifest.
If no namespace contains the marker, investigate the module first. Review its installation and service logs, Android-version support, SELinux denials and expected boot stage. A module labelled “enabled” may still have returned early from its scripts.
If every view contains the mount but the feature is absent, the problem is probably not namespace propagation. Permissions, file context, overlay priority or an application update may be responsible.
Common mistakes that cause bootloops or false results
- Installing several modules together: add one component per reboot so the failing change is identifiable.
- Using a module for the wrong root family: Magisk, APatch and KernelSU share some conventions, but their modules are not universally interchangeable.
- Testing before storage decryption: modules that depend on user storage may mount only after the first unlock.
- Reusing stale process IDs: zygote and app PIDs change after reboot or process restart.
- Assuming hiding equals integrity: filesystem concealment does not guarantee Play Integrity results or acceptance by financial apps.
- Running unreviewed shell scripts: root modules have enough privilege to steal data, lock the device or make it unbootable.
- Forgetting OTA consequences: an update can replace patched partitions or make the existing kernel incompatible.
Image caption: A minimal test stack makes it easier to distinguish an Android 17 namespace regression from a conflicting root module.
Recovering from a bad module
If Android still reaches the KernelSU manager, disable or uninstall the newest module and reboot. If the device bootloops, use the recovery method documented by the selected KernelSU fork or mount data from a trusted recovery and remove the offending module directory from /data/adb/modules/. Only remove the directory that matches the known bad module.
If the kernel itself is incompatible, restore the exact stock image to the partition that was modified. Do not relock the bootloader while non-stock or mismatched partitions remain installed; verified-boot failure can leave the device unable to start.
Readers new to boot-image recovery should review our guide to unlocking an Android bootloader safely and practical KernelSU root guide before flashing. PrivacyPortal’s privacy-first Android phones are also an option for people who want a de-Googled device without maintaining a custom root stack themselves.
Frequently asked questions
Does SUSFS for KernelSU automatically fix missing Android 17 module mounts?
No. SUSFS can control concealment and unmount behaviour, but a late-created module mount may still be absent from an existing clean namespace. The kernel, SUSFS userspace component and module must agree on how and when the mount is created.
Should I enter the real zygote and dummy zygote_next namespaces manually?
Not as a generic fix. That technique remains a community proposal rather than a confirmed universal Android 17 procedure. Process selection, mount propagation and SELinux rules vary between builds. Use it only when a trusted maintainer documents it for the exact kernel and module combination.
Why does the module work when KernelSU’s “Umount modules” option is disabled?
The module probably needs its mounted files to remain visible to the target app. Enabling the option deliberately gives non-root apps a view without module mounts, which conflicts with that requirement.
Will SUSFS make banking apps or Play Integrity pass?
There is no guarantee. Apps can use hardware-backed attestation, boot state, behavioural signals and private detection logic beyond filesystem mounts. A configuration that works today may fail after an app, server or operating-system update.
Can an incompatible module permanently brick a phone?
Most module bootloops are recoverable by removing the module or restoring stock images, but flashing the wrong partition or relocking with mismatched images can cause a more serious failure. Maintain an off-device backup and a tested recovery route before modifying the kernel.
Is KernelSU safer than Magisk?
KernelSU moves root control into the kernel and can reduce some userspace exposure, but it is not automatically safer. Security depends on the kernel source, build provenance, granted applications and installed modules. Any root manager expands the consequences of trusting a malicious component.
