TL;DR: SUSFS for KernelSU does not remain mounted unchanged through a reboot. KernelSU reconstructs module overlays during boot. If a module appears unmounted afterwards, the usual causes are per-app hiding, a KernelSU 3.x metamodule mismatch, incompatible SUSFS kernel and userspace components, or an OTA, slot or Kernel Module Interface change.
By the PrivacyPortal team
Last updated 23 July 2026
When KernelSU or SUSFS modules disappear after restarting a Generic Kernel Image device, the files have not necessarily been deleted. KernelSU modules are stored on persistent data, but their live mounts are temporary and must be recreated at every boot. Start by checking the manager, kernel support, module state and target application rather than repeatedly reinstalling ZIP files. A module visible in one process but hidden from a banking app can be working exactly as configured.
Why SUSFS for KernelSU appears to unmount after reboot
A KernelSU module is not a conventional Android application or a permanent modification to the system partition. Its files normally live under /data/adb/modules. During boot, KernelSU reads the module metadata, executes the appropriate scripts and reconstructs the module’s systemless overlays.
“Systemless” means files can appear to replace parts of Android without rewriting the read-only system partition. The resulting mount exists in memory and in one or more Linux mount namespaces. Rebooting destroys those live namespaces, so KernelSU must build them again.
If reconstruction fails, common causes include:
- The module has been disabled, removed or marked for an update.
- A required metamodule is absent or incompatible with the installed KernelSU generation.
- The SUSFS userspace module does not match the SUSFS patch compiled into the kernel.
- An over-the-air update changed the active slot, boot image, kernel or Kernel Module Interface.
- A boot script failed because encrypted data was not yet available.
- Another root module changed the same paths or mount rules.
- SUSFS deliberately hid the mount from the application used to inspect it.
KernelSU’s official module guide defines modules as persistent directories under /data/adb/modules whose scripts and systemless mounts are processed during Android boot.
A module directory persists on data storage, while its live overlay is rebuilt inside Android’s boot-time mount environment.
GKI changes the diagnosis
Android’s Generic Kernel Image, or GKI, separates the common Android kernel from device-specific vendor modules. It improves kernel consistency, but it does not make arbitrary boot or kernel images interchangeable. The device still depends on the correct Android release, architecture, kernel version, vendor modules and Kernel Module Interface, commonly shortened to KMI.
A SUSFS-capable kernel must contain a compatible SUSFS patch. Installing only a userspace SUSFS module cannot add missing kernel functionality. Conversely, a kernel with SUSFS built in may expose core support without a separate module, although a matching userspace component can still be needed for additional rules and controls.
Android’s official GKI documentation states that devices launching with Android 12 and Linux kernel 5.10 or newer must use the GKI architecture.
An OTA can boot the other A/B slot with a new stock kernel. KernelSU Manager may remain installed as an ordinary app, and module directories may remain on data, while kernel-level root is no longer active. This combination often looks like a module problem even though the real change occurred below the module layer.
See the official Android Generic Kernel Image documentation for the architecture and KMI model, and the official KernelSU introduction for KernelSU’s kernel-based design.
Unmounted, hidden or never mounted?
| What you observe | Most likely explanation | Best first check |
|---|---|---|
| Module is enabled and works globally, but one app cannot see its files | Expected per-app namespace unmounting or SUSFS hiding | Compare a root shell with the target app’s process context |
| Every systemless module stops working after a KernelSU update | Missing or incompatible metamodule, or changed mount implementation | Check the manager’s module documentation and compatibility notes |
| SUSFS controls report unsupported after boot | Kernel patch absent, inactive or incompatible with userspace | Confirm the running kernel rather than the downloaded image |
| KernelSU reports not installed after an OTA | The new slot contains an unpatched boot or init_boot image | Check the active slot, build number and running kernel |
| Only one module fails while others work | Bad boot script, conflict, stale update or module-specific incompatibility | Disable that module and inspect its logs and metadata |
| Device bootloops after installing a ZIP | Incompatible module, kernel or boot-stage script | Use the manager’s safe-mode or module-removal recovery method |
KernelSU 3.x metamodules and mount changes
KernelSU 3.x changed assumptions around how systemless module mounting is supplied. Depending on the exact KernelSU implementation or fork, a metamodule may provide the mounting engine used by ordinary modules. A metamodule is a foundational module that performs work on behalf of other modules rather than merely adding a feature of its own.
The practical failure pattern is distinctive: root remains available, modules remain listed, their files still exist, but replacements under system paths are missing after reboot. Installing random versions of several mounting modules usually makes diagnosis harder. Use the one recommended by the documentation for your exact manager and kernel combination.
KernelSU, KernelSU Next and SukiSU Ultra are related but not interchangeable at every layer. Their managers, kernel integrations, SUSFS builds and recommended metamodules can diverge. Do not install a file merely because its name contains “KSU”. Check the supported fork, KernelSU generation, Android version, kernel branch and release notes.
PrivacyPortal’s verification on 23 July 2026 found that persistent module files combined with missing post-boot overlays most often indicates mount reconstruction failure, not deletion.
Safety checks before changing the kernel
Back up first. Copy photos, authenticator recovery material, documents and anything else that cannot be replaced. Keep the exact factory images for the currently installed build somewhere other than the phone.
Unlocking the bootloader wipes user data on standard Android implementations. It can also affect warranty support, verified boot status, OTA installation and the behaviour of security-sensitive applications. Flashing the wrong boot, init_boot or vendor_boot image can leave the device unable to start. Recovery may require a computer, the correct factory image and a functioning bootloader connection.
Root and an unlocked bootloader weaken parts of Android’s security model. SUSFS can conceal selected filesystem and mount indicators, but it does not restore a cryptographically locked stock state. Banking, workplace, streaming and payment applications can use Play Integrity alongside their own checks. No KernelSU or SUSFS configuration can be promised to pass a particular app’s detection.
If the objective is privacy rather than experimentation, a supported operating system on compatible hardware may be a better trade-off. PrivacyPortal’s Android bootloader unlocking guide explains the consequences to consider before modifying your own device.
How to install and verify SUSFS for KernelSU
Prerequisites
- An unlockable device that you own and have backed up.
- The exact stock images for the installed build and region.
- A supported GKI device and a KernelSU-compatible kernel for its precise KMI.
- A SUSFS-patched kernel or boot image built for that device and software release.
- The matching KernelSU Manager, KernelSU Next Manager or SukiSU Ultra Manager.
- The compatible SUSFS userspace module and, where required, the recommended metamodule.
- A computer with the device manufacturer’s USB drivers and current Android platform tools.
Use the named packages in the automatically appended Modules, apps & files to try section where they match your root implementation. Do not mix managers or modules between forks without explicit compatibility documentation.
Numbered installation procedure
- Record the working state. In Android settings, note the full build number. In the current root manager, record its version, KernelSU version, kernel release, active modules and any displayed SUSFS version. Check the active A/B slot if the device uses seamless updates.
- Prepare recovery files. Download the factory package matching the installed build. Extract the original boot-related images and confirm that the bootloader can see the device. Do not proceed if the only recovery copy is stored on the phone.
- Confirm kernel compatibility. Match the candidate SUSFS kernel or patched image against the exact device, Android build, kernel branch and KMI. A matching Android version alone is insufficient. Never flash an image intended for a similarly named model.
- Unlock only if necessary. Follow the manufacturer’s official bootloader procedure. Expect the unlock operation to erase the phone completely. Re-enable developer options and USB debugging after initial setup if they are needed for recovery.
- Install the kernel component. Follow the maintainer’s device-specific instructions for boot, init_boot, vendor_boot or a custom kernel package. Partition layouts vary, so a generic flashing command is unsafe. Boot the device once before adding optional modules and verify that the manager reports kernel-level root.
- Install the required metamodule. If the documentation for that KernelSU 3.x implementation specifies a mounting metamodule, open the manager’s Modules page, choose its install-from-storage action, select the exact compatible ZIP and reboot. Use only one mounting implementation unless its documentation explicitly permits another.
- Install the matching SUSFS userspace module. From the same Modules page, install the release intended for the running SUSFS kernel patch and root-manager fork. Reboot again. If SUSFS is fully integrated and the maintainer says no companion module is required, do not add one merely for completeness.
- Verify each layer. Confirm that the root manager recognises the running kernel, the metamodule is enabled where required, and the SUSFS interface reports supported rather than unavailable. Then test an ordinary systemless module with a visible, reversible effect.
- Test hiding separately. Check the visible mount from a trusted root shell, then compare it with the target application. If it disappears only inside the target app, per-app unmounting is probably working. Do not interpret successful concealment as a missing global mount.
- Reboot twice. A second cold boot exposes ordering problems that a first post-install boot may not reveal. If the overlay fails, disable the newest optional module first and preserve logs before reinstalling anything.
A reliable verification checks the running kernel, mount engine and SUSFS interface separately instead of treating the manager’s module list as proof.
What to do when modules still disappear
Change one layer at a time. Reinstalling the kernel, manager, metamodule and SUSFS module together removes the evidence needed to identify the fault.
- Check disable markers: a disable file inside a module directory tells the framework not to load it.
- Check removal state: a module marked for removal can remain visible until the next reboot and then disappear.
- Check data availability: scripts requiring credential-encrypted files may run before those files become accessible.
- Check script permissions and line endings: Windows-style line endings or a missing executable permission can break shell scripts.
- Check conflicts: two modules replacing the same path can produce order-dependent results.
- Check free space: low space under data can interrupt extraction, updates or log creation.
- Check the actual slot: an OTA may leave the patched image on the inactive slot.
- Check kernel logs: look for module script errors, mount failures, unsupported SUSFS commands and security-policy denials.
If the phone bootloops, use the root implementation’s documented safe mode or recovery-time module removal. Remove only the most recently installed suspect module first. Avoid wiping data until the correct stock image and less destructive recovery options have been tried.
The official KernelSU module guide documents module layout and boot scripts. For broader preparation and recovery principles, see PrivacyPortal’s guide to rooting Android safely.
Handling OTAs without losing the working setup
Treat every OTA as a kernel change until proven otherwise. Record the current configuration before updating, disable fragile optional modules and obtain the new build’s factory images. A patched image from the previous release may have the wrong KMI or ramdisk contents even when the phone model is unchanged.
On A/B devices, the update is normally written to the inactive slot and becomes active after reboot. KernelSU can therefore vanish while its manager and data remain installed. Patch or install only through the procedure supported for the new build and the selected KernelSU fork. Never flash the old patched image over a newly updated slot simply to restore root.
Automatic OTA installation may fail or be unsafe with modified boot components. Accepting manual maintenance is part of the cost of running a custom kernel. Keep a known-good stock route available and wait for compatible SUSFS releases when a new kernel has not yet been validated.
Frequently asked questions
Are KernelSU modules deleted when the phone reboots?
Normally, no. Module files persist under /data/adb/modules, but their live systemless mounts do not. KernelSU reconstructs those mounts during boot. Check module markers, scripts, the mounting metamodule and the running kernel before reinstalling the ZIP.
Can I install SUSFS as a module on an unpatched stock kernel?
No ordinary userspace module can create the required kernel functionality. SUSFS needs compatible support compiled or patched into the running kernel. A companion module communicates with that support and manages additional hiding rules; it is not a substitute for the kernel patch.
Why can a root shell see a mount that a banking app cannot?
Linux mount namespaces allow different processes to see different mount tables. KernelSU or SUSFS may deliberately unmount root-related paths for a selected application. This can indicate that hiding is functioning, but it does not guarantee the app will accept the device or pass Play Integrity.
Will SUSFS make every banking app work?
No. Applications can inspect bootloader state, integrity verdicts, installed software, behavioural signals and their own server-side risk data. Detection changes frequently, and no method can guarantee compatibility with a named bank or payment application.
Why did SUSFS stop working immediately after an OTA?
The OTA may have activated a new slot containing a stock kernel, or it may have changed the kernel and KMI. Verify the active slot, full build number, running kernel and KernelSU status. Use components built specifically for the new release.
Should I use KernelSU, KernelSU Next or SukiSU Ultra?
Choose according to device support, maintained kernel builds and documented SUSFS compatibility rather than hiding claims alone. SukiSU Ultra and KernelSU Next are popular SUSFS-oriented paths, but their managers and kernel components are not universally interchangeable. A maintained, recoverable configuration is preferable to a more complex stack built from unrelated releases.
