TL;DR: SUSFS for KernelSU only works when SUSFS patches are compiled into a compatible kernel. The installable module supplies userspace controls; it cannot patch an unsupported kernel. Match the kernel, Kernel Module Interface, security patch and device build exactly, back up first, and keep stock images ready for recovery.
By the PrivacyPortal team
Last updated July 2026
SUSFS for KernelSU is a kernel-level concealment system intended to reduce filesystem and mount signals exposed by a rooted Android device. It requires two cooperating parts: SUSFS support inside the running kernel and a compatible userspace management layer. A KernelSU module by itself cannot add missing kernel functionality. Installing the wrong kernel can cause a boot loop, loss of connectivity or a hard-to-recover device, while unlocking the bootloader normally wipes all user data. Back up before doing anything, confirm that you can restore the factory images, and never assume SUSFS will make a banking or protected app work.
SUSFS for KernelSU: why modules alone are not enough
SUSFS, short for SUS File System, changes how selected filesystem paths, mounts and related kernel information are presented to userspace. This is materially different from a conventional root-hiding module that tries to alter results after Android has already received them.
The important distinction is where the code runs. KernelSU provides root from the kernel, and SUSFS extends the kernel with additional concealment functions. The downloadable SUSFS4KSU module normally acts as a userspace helper: it configures features exposed by those compiled patches. If the interface does not exist in the running kernel, the helper has nothing to control.
The official SUSFS4KSU project distributes kernel patches and a KernelSU userspace module as separate parts of the same system.
Some custom kernels package both layers or integrate the required scripts themselves. In that case, the maintainer may explicitly say that no separate module is needed. Follow the instructions for that exact kernel release rather than installing another copy automatically.
Image caption: SUSFS works as a two-layer system, with kernel patches underneath the userspace control module.
What kernel compatibility actually means
An Android version is not a sufficient compatibility check. Two phones running Android 16 can have different kernel branches, Kernel Module Interfaces, vendor changes, security-patch levels and boot-image layouts.
The Kernel Module Interface, or KMI, defines the interface between an Android Generic Kernel Image and compatible vendor modules. A kernel that does not match the expected KMI may boot but lose Wi-Fi, mobile data, cameras or other hardware. It may also fail before Android starts.
Android’s Generic Kernel Image documentation states that devices launching with Android 12 and Linux 5.10 or newer must use the GKI kernel architecture.
Before downloading anything, compare all of the following:
- Device identity: exact model, regional variant and device codename.
- Kernel release: the complete kernel string, not merely “5.10” or “6.1”.
- KMI generation: for example, the complete Android and kernel branch shown by the build.
- Firmware baseline: ROM build and Android security-patch level supported by the kernel release.
- Root implementation: KernelSU, KernelSU Next or SukiSU Ultra, as specified by the maintainer.
- Packaging: boot, init_boot, vendor_boot or a flasher ZIP intended for the device.
A filename that contains the right Android release is not proof of compatibility. Use a kernel only when its maintainer names your codename and firmware baseline.
KernelSU, KernelSU Next and SukiSU Ultra compared
| Root family | Where root is implemented | SUSFS requirement | Practical consideration |
|---|---|---|---|
| KernelSU | Kernel space | A compatible kernel compiled with the relevant SUSFS patches | Older or device-specific integrations may require manual kernel building |
| KernelSU Next | Kernel space | A matching KernelSU Next kernel with explicit SUSFS support | Do not assume every GKI image includes SUSFS |
| SukiSU Ultra | Kernel space | A SukiSU-compatible kernel build with its supported SUSFS integration | Use the manager and kernel releases recommended together |
| Magisk | Boot-image and userspace mechanisms | Not a substitute for a SUSFS-patched KernelSU kernel | A SUSFS4KSU module cannot turn Magisk into a kernel-level SUSFS installation |
The safest choice is not automatically the newest fork. It is the combination actively maintained for your device, firmware and kernel branch. The official KernelSU installation guide explains the distinction between GKI installation and integrating KernelSU into a device kernel.
Risks to understand before installation
Back up photos, messages, authenticator recovery codes, app data and anything else that cannot be replaced. Copy the backup off the phone. Bootloader unlocking normally performs a factory reset, and later recovery work may wipe the device again.
- Boot failure: an incompatible boot or kernel image can leave the phone looping at the logo or returning to fastboot.
- Hardware failure: a KMI or vendor-module mismatch may break Wi-Fi, Bluetooth, cameras, audio or mobile connectivity.
- Updates: over-the-air updates may fail, overwrite root or require repatching the new stock image.
- Warranty and support: bootloader unlocking or custom software may affect warranty handling, depending on the seller and jurisdiction.
- Security: root expands the damage a malicious or carelessly authorised app can cause. Grant root only to software you trust.
- App compatibility: Play Integrity, bootloader state, hardware attestation and app-specific checks are separate from filesystem hiding.
SUSFS is not a guarantee of passing Play Integrity or any bank’s detection. An app can change its checks without notice. Relocking the bootloader while modified images remain installed can also brick some devices; do not relock unless the device’s verified-boot requirements are fully understood and stock-compatible images have been restored.
For a broader threat-model discussion, see PrivacyPortal’s guide to what a de-Googled phone changes—and what it does not.
How to install SUSFS for KernelSU safely
This procedure is deliberately device-neutral because partition names and flashing commands are not interchangeable between manufacturers. Obtain the manager, kernel package and SUSFS4KSU helper named in the automatically appended Modules, apps & files to try section, then confirm them against the maintainer’s instructions.
- Record the current configuration. Note the exact model, codename, build number, Android security-patch date, full kernel string, active slot and current root manager. Screenshots are useful only if they are also copied off the phone.
- Create an off-device backup. Back up personal data and export recovery codes. Obtain the matching factory firmware, including the original boot, init_boot, vendor_boot and vbmeta images where the device package supplies them.
- Confirm a recovery route. Verify that the computer detects the phone in Android and bootloader mode. Install the correct platform tools and drivers. Learn the device’s documented method for entering fastboot, fastbootd or download mode before modifying it.
- Unlock only when required. Follow the manufacturer’s bootloader-unlock procedure for your own device. Expect a complete data wipe. Some manufacturers do not provide an official unlock path.
- Select an explicitly compatible kernel. Choose a release that names your device codename, kernel or KMI branch, firmware baseline, root implementation and SUSFS support. “KernelSU supported” does not necessarily mean “SUSFS included”.
- Verify the download. Use the maintainer’s official release page, check any published hash or signature, and read release notes for partition requirements. Do not flash a repackaged image from an untraceable mirror.
- Install the matching manager. Use KernelSU Manager, KernelSU Next Manager or the SukiSU Ultra manager specified by the kernel maintainer. Mixing managers and unrelated kernel generations can produce misleading status information.
- Install the kernel using its documented method. Some releases provide a boot or init_boot image; others use an AnyKernel-style ZIP with an app such as Horizon Kernel Flasher. Flash only the partition or package named by the maintainer. If temporary booting is officially supported, test-booting is safer than immediately writing the image.
- Boot and check basic hardware first. Before adding modules, verify calls, mobile data, Wi-Fi, Bluetooth, cameras, audio, charging and biometric authentication. Restore the stock image if essential hardware is broken.
- Add the SUSFS userspace layer only if required. Install the official SUSFS4KSU module through the root manager when the kernel instructions require it, then reboot. Do not install duplicate SUSFS modules when the kernel package already bundles its management layer.
- Verify actual support. Open the module WebUI or status screen. It should report that SUSFS is supported and active, not “SUSFS not supported”. Confirm that KernelSU root works and review the manager log for unsupported commands, version mismatches or failed post-mount actions.
- Add other components one at a time. Reboot and retest after every module. Do not install a large hiding stack at once: overlapping mount rules and path lists make failures much harder to diagnose.
Image caption: Record the complete kernel and build information before choosing a SUSFS-compatible download.
How to diagnose “SUSFS not supported”
“SUSFS not supported” normally means the running kernel does not expose the interface expected by the userspace helper. Reinstalling the same module will not repair that.
- Check whether an OTA restored the stock boot or init_boot image.
- Confirm that the phone booted the intended slot after flashing.
- Compare the installed helper version with the kernel maintainer’s required release.
- Check whether the downloaded build actually says “SUSFS”, rather than only “KernelSU”.
- Remove duplicate or obsolete SUSFS helper modules.
- Review the root manager log before adding any other hiding components.
If the phone boot-loops, return to the bootloader and restore the original image for the partition you changed. A module-induced loop may be recoverable by the root manager’s safe mode or module-disable procedure, but that mechanism varies. Do not experiment with unrelated vbmeta flags during recovery.
Image caption: A clean verification sequence separates kernel compatibility failures from module conflicts.
A practical decision framework
Proceed only when every answer below is clear:
- Is there a maintained build for the exact codename? If not, stop unless you can audit and compile the kernel yourself.
- Does it match the current firmware and KMI? If not, update or downgrade only through a documented device procedure.
- Does the release explicitly include SUSFS? KernelSU support alone is insufficient.
- Can the original images be restored? If not, establish a recovery route before flashing.
- Is the goal worth an unlocked, modified device? For high-assurance banking or workplace apps, a separate unmodified phone is often the more dependable solution.
A passing result today is not a permanent compatibility promise: protected apps can combine Play Integrity, boot-state signals and their own detection rules.
Readers who would rather avoid bootloader modification can start with practical Android privacy settings that do not require root. Root concealment is a specialised modification, not a prerequisite for meaningful privacy.
Common SUSFS pitfalls
- Installing the SUSFS4KSU module on a stock or otherwise unpatched kernel.
- Choosing a kernel by Android version while ignoring codename, KMI and security-patch level.
- Flashing a boot image when the maintainer supplied an init_boot image, or vice versa.
- Mixing KernelSU, KernelSU Next and SukiSU Ultra components from unrelated releases.
- Combining SUSFS with aggressive path-hiding modules before verifying a clean baseline.
- Assuming more modules produce better concealment; conflicting mount rules can create new anomalies.
- Testing only Play Integrity while overlooking broken radios, cameras or OTA behaviour.
- Relocking the bootloader with a custom kernel still installed.
Frequently asked questions
Can I install SUSFS on any KernelSU phone?
No. The running kernel must contain compatible SUSFS patches. KernelSU root access alone does not prove that SUSFS is present.
Can the SUSFS module patch my kernel?
No. The module is a userspace management layer. Kernel patches must already be compiled into the kernel or supplied through a compatible maintainer-built kernel package.
Does SUSFS work with Magisk?
SUSFS4KSU is designed around kernel support and KernelSU-family integrations. Installing its module under Magisk does not add the required kernel code. Use only combinations explicitly supported by their maintainers.
Will SUSFS make my banking apps work?
There is no guarantee. Banks and other protected apps use different and changing checks, potentially including bootloader state, Play Integrity, hardware-backed signals and their own heuristics. Never rely on a claimed universal bypass.
Does SUSFS automatically pass Play Integrity?
No. SUSFS primarily addresses selected filesystem and mount visibility. Play Integrity evaluates additional device and software signals, and its results can change independently.
Why did SUSFS stop working after an OTA update?
An OTA may replace the patched boot, init_boot or kernel image with a stock version. The updated firmware may also use a different kernel or KMI baseline. Obtain a newly compatible build rather than reflashing an old image blindly.
What should I keep for recovery?
Keep an off-device personal backup, matching factory firmware, original images for every partition you modify, current platform tools and the manufacturer’s recovery instructions. Confirm that the computer can detect the phone in bootloader mode before flashing.
