Do SUSFS Modules Add SUSFS Support to KernelSU Next?

TL;DR: No. A SUSFS4KSU module does not add SUSFS support to an ordinary KernelSU Next kernel. For susfs for kernelsu to work, SUSFS must already be compiled into the kernel. The module only supplies the userspace scripts, helpers and WebUI controls that communicate with the kernel implementation.

By the PrivacyPortal team

Last updated 20 July 2026

Installing SUSFS4KSU on an unsupported kernel will not patch that kernel or activate filesystem-level hiding. In practice, the module may install successfully while its WebUI reports that SUSFS is unsupported. You need a device-specific kernel or boot image that explicitly includes compatible KernelSU Next and SUSFS patches, followed by the matching userspace module. Back up everything before proceeding: unlocking the bootloader normally wipes the phone, and flashing the wrong boot, init_boot or kernel image can cause a boot loop or brick the device. Root can also affect warranty support, over-the-air updates, device security, Play Integrity and banking apps.

Image caption: Kernel support sits beneath the KernelSU Next manager and SUSFS4KSU userspace module.

What SUSFS for KernelSU actually consists of

SUSFS, short for “sus filesystem”, is a set of Linux kernel modifications intended to conceal selected filesystem artefacts and other signs associated with root or device modification. It operates below an ordinary Android root-hiding module because the relevant behaviour is implemented inside the kernel.

A functional susfs for kernelsu setup has two distinct parts:

• A SUSFS-patched kernel: the device kernel contains the actual SUSFS implementation, compiled for the correct device, Android kernel branch and KernelSU integration.
• The SUSFS4KSU module: userspace scripts and controls send configuration to the implementation already present in that kernel.

The second part cannot substitute for the first. This is similar to installing a control panel for hardware that the phone does not contain: the interface may be present, but there is nothing underneath it to perform the requested operation.

As of 20 July 2026, SUSFS4KSU remains a userspace companion to a SUSFS-patched kernel; it is not a kernel patcher.

The architectural distinction is visible in the official SUSFS4KSU project, which separates kernel-side patches from the userspace component.

Does KernelSU Next include SUSFS automatically?

No. KernelSU Next can support SUSFS, but installing the KernelSU Next manager or using a kernel with KernelSU Next does not prove that SUSFS is present. The kernel build must explicitly incorporate compatible SUSFS patches.

Some community-maintained GKI builds include both KernelSU Next and SUSFS. GKI means Generic Kernel Image, an Android architecture designed to reduce fragmentation between the common kernel and device-specific components. GKI compatibility can make supported builds easier to distribute, but it does not make kernel images universal.

Check the maintainer’s release notes for an explicit statement such as “SUSFS support” and verify the exact device codename, Android release, kernel branch and expected boot partition. A vague label such as “KSU kernel” is insufficient.

Non-GKI devices generally require a kernel compiled from the device’s appropriate source tree with KernelSU Next and SUSFS integrated. Even on a GKI phone, vendor modules, kernel module interfaces and Android security patch levels can make the wrong image unbootable.

Android’s GKI model standardises part of the kernel architecture, but it does not make every GKI kernel safe to flash on every GKI-labelled phone.

For the underlying model, see the Android Generic Kernel Image documentation.

Kernel, manager and module: what each component does

Component	Primary role	Can add SUSFS kernel support?	Typical failure signal
KernelSU Next manager	Manages root access, modules and applications permitted to use root	No	Manager works, but no usable SUSFS interface exists
KernelSU Next-enabled kernel	Provides kernel-based root	Only if SUSFS was also included when built	Root works while SUSFS4KSU reports unsupported
SUSFS-patched KernelSU Next kernel	Implements SUSFS functionality inside the kernel	Yes, because support is already compiled in	Boot failure if the build is incompatible with the device
SUSFS4KSU module	Provides scripts, helpers, configuration and WebUI controls	No	Module installs but reports “SusFS not supported” or equivalent
Root-hiding or integrity module	Changes selected userspace properties or detection surfaces	No	Conflicts, regressions or no improvement in app compatibility

This separation also explains why a module update and a kernel update are not interchangeable. A newer module may expect kernel features that an older build lacks. Conversely, a newer kernel implementation may require a compatible userspace release.

How to decide whether your device is ready

Use this decision framework before downloading or flashing anything:

1. Confirm the exact device identity. Record the manufacturer, model, codename, regional variant and active Android build. Similar retail names can hide materially different hardware.
2. Identify the kernel route. Determine whether the device uses a supported GKI configuration or needs a device-specific custom kernel build.
3. Find explicit SUSFS evidence. The kernel maintainer must state that SUSFS is included. Do not infer support from “KernelSU Next”, “KSU” or “rooted”.
4. Match the release details. Compare the device codename, Android version, kernel branch, security patch context and required KernelSU Next or SUSFS release pairing.
5. Check the recovery path. Keep the original boot-related images and know how to access the bootloader before modifying the phone.

If any answer is uncertain, stop. Asking the kernel maintainer for the supported build combination is safer than testing a plausible-looking image. The official KernelSU Next repository is the appropriate starting point for project documentation and current releases.

How to install and verify SUSFS with KernelSU Next

This procedure assumes you already have a device-compatible kernel build whose maintainer explicitly confirms KernelSU Next and SUSFS support. Partition layouts and flashing methods vary, so the kernel maintainer’s device-specific instructions take precedence.

1. Back up the phone. Copy photos, documents, authenticator recovery material and any app data you cannot replace. A bootloader unlock normally performs a factory reset. Treat the backup as mandatory even if the bootloader is already unlocked.
2. Record the current build. Note the device codename, Android build number, security patch level, kernel version and KernelSU Next manager version. These details are essential if you need to diagnose a mismatch.
3. Prepare a recovery route. Obtain the original boot, init_boot and other relevant factory images for the exact installed firmware. Verify that a computer can detect the phone in its bootloader interface before flashing.
4. Verify the kernel package. Use only a release from the device maintainer or another source you can authenticate. Check any published checksum and confirm which partition or installer method the build targets. Never flash a generic-looking image solely because the phone supports GKI.
5. Install the SUSFS-enabled kernel. Follow the build maintainer’s exact procedure. Depending on the device, this may involve boot, init_boot, vendor_boot, a custom recovery installer or another supported mechanism. Do not guess the partition.
6. Boot and test the base system. Confirm that Android starts, mobile data, Wi-Fi, cameras and other essential hardware work. Open KernelSU Next and verify that its kernel support is active before adding modules.
7. Install the compatible SUSFS4KSU module. Select the verified module package through KernelSU Next’s module interface. Use the item named SUSFS4KSU in the automatically appended “Modules, apps & files to try” section, and confirm that its release is intended for your kernel implementation.
8. Reboot when instructed. After rebooting, open the module’s WebUI. Confirm that it detects kernel-side SUSFS support rather than displaying “SusFS not supported”. A successful module installation notification alone is not verification.
9. Test incrementally. Check normal phone functions first, then test the applications you personally rely on. Do not install several hiding or integrity modules at once; simultaneous changes make conflicts difficult to isolate.
10. Keep a rollback copy. Retain the known-good original images and the working custom-kernel package. Recheck compatibility before every Android OTA or kernel update.

Image caption: The SUSFS4KSU WebUI should confirm kernel support after the patched kernel and matching module are installed.

What “SusFS not supported” means

If the WebUI reports “SusFS not supported”, the userspace module cannot find a compatible SUSFS implementation in the running kernel. Reinstalling the same module, granting it more root permissions or adding another hiding module will not create that missing kernel functionality.

The most common causes are:

• The phone is running ordinary KernelSU Next without SUSFS patches.
• The patched image was flashed to the wrong slot or partition, leaving the previous kernel active.
• An OTA restored or replaced the modified boot components.
• The kernel and module use incompatible SUSFS interfaces or releases.
• The downloaded build targets a different device, Android base or kernel branch.
• The flash failed, but the phone fell back to a bootable slot containing the old kernel.

Check the kernel version shown after boot against the maintainer’s expected identifier. If they differ, determine which slot and image the phone actually loaded. If they match but support remains unavailable, return to the maintainer’s compatibility notes rather than forcing commands copied from another device.

Image caption: An unsupported message usually identifies a missing or incompatible kernel implementation, not a failed WebUI installation.

Real risks and failure modes

Kernel modification changes one of Android’s most trusted components. A malicious or carelessly built kernel can access essentially everything the operating system can access. A malicious root module can also execute privileged commands, steal data or deliberately prevent the phone from booting.

Never install modules distributed only through an unknown chat account or an untraceable file host. Review the project history, source, maintainer identity, release provenance and community reports. A copied module name or module.prop file does not establish authenticity.

Operational risks include:

• Boot loops or a non-booting device after flashing an incompatible image.
• Data loss during bootloader unlocking or recovery.
• Broken cameras, radios, encryption or other device-specific functions.
• OTAs failing, overwriting the patched kernel or booting the wrong slot.
• Reduced protection if root access or module permissions are mismanaged.
• Warranty or support complications depending on the manufacturer and jurisdiction.
• Banking, wallet, streaming or workplace apps refusing to run.

No SUSFS, KernelSU Next or module configuration can guarantee that a particular banking app or Play Integrity verdict will continue to work.

Detection changes over time and may examine bootloader state, hardware-backed attestation, ROM properties, installed applications, runtime behaviour and server-side risk signals. SUSFS addresses selected surfaces; it is not a universal attestation bypass.

Common setup mistakes to avoid

• Treating SUSFS4KSU as a patcher: it controls kernel functionality; it does not compile or inject that functionality into an unsupported kernel.
• Assuming all GKI images are interchangeable: GKI reduces fragmentation but does not remove device, vendor-module or release compatibility requirements.
• Flashing before securing factory images: recovery is much harder when the original firmware cannot be identified.
• Stacking modules immediately: overlapping hiding, Zygisk and integrity tools can conflict or make a working configuration regress.
• Following outdated screenshots: menu names and compatible combinations change. Use current project documentation and release notes.
• Updating Android blindly: an OTA can replace boot components or make an existing patched kernel incompatible.
• Trusting a successful install banner: verify the running kernel and the WebUI’s support status after reboot.

For readers still deciding whether system modification is appropriate, PrivacyPortal’s guide to de-Googling Android covers less invasive privacy choices. Root is powerful, but it is not required for every privacy improvement.

Frequently asked questions

Can I install SUSFS on stock KernelSU Next using only a module?

No. SUSFS must be compiled into the running kernel. SUSFS4KSU adds userspace helpers and controls, not the kernel implementation.

How can I tell whether my kernel supports SUSFS?

Look for an explicit SUSFS statement in the kernel maintainer’s release notes, then verify the module WebUI after boot. “KernelSU Next supported” does not by itself mean “SUSFS supported”.

Does a GKI phone automatically support SUSFS?

No. GKI can make compatible kernel distribution easier, but the selected build must still contain SUSFS and match the device’s Android, kernel and vendor requirements.

Will SUSFS make every banking app work?

No. Apps use different and changing detection methods, sometimes including hardware-backed or server-side checks. No guide can promise that a configuration will pass a specific bank’s checks.

Is SUSFS compatible with Magisk?

SUSFS4KSU is designed around KernelSU-family integration and a patched kernel. Installing it as though it were an ordinary Magisk hiding module does not add SUSFS support. Root-manager module formats may look similar while relying on different kernel and runtime mechanisms.

What should I do before an Android OTA?

Back up current data, obtain the new firmware’s recovery images, and wait for confirmation that the patched kernel supports the updated build. An OTA may overwrite the modified image or leave the active slots with different kernels.

What is the safest response to “SusFS not supported”?

Stop adding modules. Confirm the running kernel identifier, active firmware, device codename and maintainer-supported release pairing. Restore a known-good image if the installed build is wrong or unstable.

The practical answer

SUSFS4KSU does not turn an ordinary KernelSU Next kernel into a SUSFS-capable one. A reliable susfs for kernelsu setup starts with a correctly built, device-compatible kernel containing both KernelSU integration and SUSFS patches. The module comes afterwards as the userspace control layer.

The safest order is simple: back up, confirm the exact device and firmware, secure a rollback path, verify explicit kernel support, flash only through documented device-specific instructions, test the base kernel, install the matching module, and verify support in its WebUI. If the evidence is incomplete, waiting for a maintained build is safer than experimenting with an unverified kernel image.