SUSFS: How to Hide Mounts with sus_mount

TL;DR: SUSFS hides KernelSU-related filesystem mounts inside a supported kernel. On SUSFS v2.2.0, SUS_MOUNT handles KernelSU-created mounts automatically. The old ksu_susfs add_sus_mount command and custom sus_mount.txt workflow are deprecated. You need a compatible patched kernel, the correct userspace helper and a full backup before changing anything.

By the PrivacyPortal team

Last updated 24 August 2026

SUSFS is an experimental KernelSU patchset with a userspace helper. It can hide root-related mounts and paths from apps which inspect the filesystem. It is not a universal detection bypass. Current upstream GKI branches report SUSFS v2.2.0, which automatically manages mounts created by KernelSU. Most users should therefore avoid old manual sus_mount instructions. Installing it requires a kernel built with matching support. Unlocking the bootloader wipes the phone, while flashing the wrong image can stop it booting. Back up first and keep the exact stock boot images for recovery. Banking apps, media services and games may still reject a modified device. No setup can promise compatibility with a particular app.

A compatible kernel and its userspace helper form the two working parts of a SUSFS installation.

What SUSFS actually does

SUSFS, short for “sus filesystem”, changes selected filesystem behaviour inside the Android kernel. This lets a supported root system conceal mounts, files and paths which could otherwise reveal modification.

The design has two parts. The kernel must contain the matching SUSFS patches. A companion userspace helper then sends settings to that kernel interface. A ZIP called a susfs module cannot add missing kernel code by itself.

This distinction explains the common susfs not found error. It usually means the helper cannot reach a compatible kernel implementation. It can also mean the kernel and helper use incompatible interfaces.

Upstream GKI branches reported SUSFS v2.2.0 as of 24 August 2026.

Filesystem hiding can reduce obvious traces. It does not create a locked or stock boot state. Apps can inspect bootloader status, verified boot data, root services and other signals. Server-side rules can also change without warning.

Why the old sus_mount guide is now legacy

Older guides tell users to run ksu_susfs add_sus_mount or maintain a custom sus_mount.txt file. That workflow predates the current automatic handling.

In SUSFS v2.2.0, SUS_MOUNT handles mounts created by KernelSU. The upstream project marks the manual add_sus_mount command as deprecated. Copying an old list into a current setup may add no value. It can also hide the wrong path or make troubleshooting harder.

A custom list may still appear in an older module, fork or device-specific build. Treat its documentation as version-bound. Check the kernel commit, helper release and maintainer notes together. Do not assume that a 2024 or 2025 command applies to a 2026 build.

SUSFS v2.2.0 deprecates manual “ksu_susfs add_sus_mount” configuration because SUS_MOUNT handles KernelSU-created mounts automatically.

Which root setups work with SUSFS?

Root setup	SUSFS position	Practical advice
KernelSU	Requires a kernel compiled with compatible patches	Match the kernel, manager and helper versions.
KernelSU Next	Often offered through a patched GKI kernel	Confirm whether the build already includes its userspace support.
SukiSU Ultra	Commonly distributed with close SUSFS integration	Follow that project’s exact device and release notes.
APatch	Compatibility depends on experimental integrations	Do not flash a KernelSU package unless the maintainer supports it.
Magisk	Not a normal SUSFS target	Use a Magisk-specific hiding design instead.

Susfs for KernelSU is the main supported use case. Phrases such as susfs kernelsu module can be misleading because the essential part lives in the kernel.

A KernelSU fork may change its interface or bundle extra components. Never mix packages solely because their names contain KernelSU. Release notes and kernel commits matter more than branding.

How to install and use SUSFS safely

This procedure is a version-aware path for your own supported device.

1. Back up everything. Copy photos, authenticator recovery data and app files off the phone. Confirm that the backup opens elsewhere.
2. Identify the exact device. Record its model, region, Android build and kernel version. Similar model names can use different boot images.
3. Check bootloader support. Read the manufacturer’s unlock process. Unlocking the bootloader wipes user data and may affect warranty or service support.
4. Keep recovery files. Obtain the stock boot, init_boot and other required images from the exact installed firmware.
5. Choose one maintained stack. Use a KernelSU, KernelSU Next or SukiSU Ultra build whose maintainer names your device and states its SUSFS version.
6. Get matching files. Use the specific kernel package, manager app and userspace helper listed under “Modules, apps & files to try”. Do not mix unrelated releases.
7. Flash by the device method. Follow the maintainer’s named partition and flashing instructions. Stop if the expected partition, slot or image differs.
8. Boot and validate root. Open the matching root manager. Confirm that its installed kernel status is healthy before adding any module.
9. Add the helper if required. Install the compatible susfs4ksu userspace package only when the kernel maintainer requires it. Reboot once.
10. Verify automatic handling. Check the helper status and logs. On v2.2.0, use SUS_MOUNT rather than creating a manual sus_mount.txt list.

Prerequisites before flashing

You need an unlockable bootloader, a supported kernel build and a computer with working platform tools. Follow the official Android SDK Platform-Tools documentation when installing ADB and Fastboot.

Charge the phone and test its cable first. Make sure Fastboot can see the device before modifying a partition. Learn how to enter recovery and bootloader modes without Android running.

Read Android’s explanation of bootloader locking and unlocking. Do not relock a modified phone unless the installed images are valid for that device. Relocking incompatible firmware can leave it unable to boot.

Android requires user data to be erased when a device transitions from a locked bootloader to an unlocked state.

How to verify that it is working

Start with the manager’s kernel status. It should recognise the installed KernelSU lineage and show the expected version. The helper should then report that the SUSFS kernel interface is available.

Review logs for errors such as susfs not found, unsupported command or interface mismatch. Test a normal reboot and a cold boot. Confirm that Wi-Fi, calls, storage and encryption still work.

Check ordinary apps before testing sensitive ones. A banking app opening is not proof that the setup is undetectable. An app failing is not proof that SUSFS is broken. The app may use Play Integrity, boot state or a remote risk decision.

Verification should begin with kernel status and clean logs, not with one banking app’s result.

Safe settings for a current setup

Use the default SUSFS policy first. Change one option at a time and reboot after each meaningful change. This makes a bad rule easier to identify.

Some helpers expose options to disable verbose SUSFS logs, remove a visible “KSU” kernel string and apply spoofing at boot. These controls vary by project and release. Use them only when the current maintainer documents them.

A button labelled “make it sus” exists in some community tools. It is not a standard Android or upstream kernel control. Record the previous state before pressing it.

Avoid broad path rules copied from chat posts. One reported example involved adding a LineageOS overlay idmap path to sus_path.txt. That caused a horizontal display fault on the affected setup. Hiding system resources can break the feature which needs them.

Modules and combinations to avoid

Root-hiding components often hook the same process, mount or property. Stacking several tools can create conflicts instead of stronger hiding.

• Do not combine SUSFS blindly with Shamiko, NoHello, TreatWheel or Zygisk Assistant.
• Do not install a second SUSFS helper because the first package reports an error.
• Do not use Integrity Box as an automatic companion. Its rules may add broad custom-ROM paths and cause faults.
• Do not flash an APatch package on KernelSU, or a KernelSU package on Magisk.
• Do not import another phone’s sus_path.txt or legacy mount list.

Some setups need a Zygisk implementation for modules which run inside Android app processes. That is separate from filesystem hiding. Choose the build recommended by the kernel maintainer. More hooks mean more possible failures and more code with root access.

Common failures and what they mean

“susfs not found” during module installation

This message normally means the kernel lacks SUSFS support. It can also indicate a version mismatch or the wrong helper package. Reinstalling the same ZIP will not patch the kernel.

Check the kernel’s release notes and build identifier. If the maintainer does not state SUSFS compatibility, return to a supported kernel or the saved stock image.

The phone bootloops after flashing

A bootloop often points to the wrong image, wrong partition or an incompatible kernel. Stop repeated flashing attempts. Enter the bootloader and restore the saved image using the device maintainer’s recovery process.

Do not relock the bootloader as a repair step. Backups kept only on the phone may be inaccessible during recovery, which is why an off-device copy matters.

Modules disappear from the manager

Some community configurations can make a module view disappear after SUSFS is enabled. This can result from an over-broad hide rule or a helper compatibility fault.

Use the manager’s documented safe mode or recovery process. Disable the most recent change first. Avoid copying a developer command from an unrelated release because internal property names can change.

Banking or media apps still fail

SUSFS only addresses part of the detection surface. An app may check Play Integrity, verified boot, bootloader state, installed packages or account risk signals.

Updates can change those checks at any time. PrivacyPortal cannot promise that root hiding will satisfy a named bank or service. For essential access, keep a supported stock device or use the provider’s web service where available.

Security, updates and recovery trade-offs

A patched kernel runs highly privileged code. Only use published source and builds from a maintainer you trust. Review the official SUSFS4KSU project repository for source, release notes and supported branches.

Over-the-air updates may replace the patched boot or kernel image. They may also change the interface expected by the manager. Remove risky modules before a major update and keep the new stock images before patching anything.

An unlocked bootloader weakens physical protection because modified images can be flashed. Root access also increases the impact of a malicious app. Grant superuser rights only when needed. Review grants often.

If maintaining this stack is not appealing, a supported de-Googled phone can provide strong privacy without a root-hiding project. PrivacyPortal’s privacy-first Android phones are configured for people who prefer a maintained daily device.

The safest recovery kit includes an off-device backup, exact stock images and tested bootloader access.

Should you use SUSFS?

SUSFS suits experienced users who need KernelSU and can recover their own phone. It offers deeper filesystem control than a userspace-only hiding module. That power also increases setup and maintenance work.

• Use it when your exact kernel supports it and you understand image recovery.
• Wait when support exists only in an untested community build.
• Stay stock when reliable banking, work-device compliance or unattended updates matter most.
• Remove it when rules break display resources, storage, updates or core apps.

For wider context, see PrivacyPortal’s guide to Android rooting risks and recovery. Privacy is not measured by how many hiding tools are installed. A small, understood setup is easier to audit and repair.

Frequently asked questions

Is SUSFS a KernelSU module?

Not by itself. SUSFS is primarily a kernel patchset. The downloadable susfs module is a userspace helper which communicates with compatible kernel code. It cannot make an unsupported kernel compatible.

Do I still need sus_mount.txt on SUSFS v2.2.0?

Normally, no. SUS_MOUNT handles mounts created by KernelSU in v2.2.0. The manual ksu_susfs add_sus_mount command is deprecated. Follow a custom list only when the maintainer documents a specific non-standard need.

Can SUSFS hide an unlocked bootloader?

It may conceal some filesystem evidence linked to a modified setup. It does not turn an unlocked bootloader into a locked one. Apps can use verified boot state and other signals outside filesystem mount checks.

Does SUSFS work with Magisk?

SUSFS is designed around supported KernelSU-lineage kernels and helpers. It is not a normal Magisk hiding module. Magisk users should follow a current Magisk-specific guide instead of flashing a KernelSU package.

Will SUSFS make every banking app work?

No. Each app chooses its own checks, and those checks can change remotely. SUSFS cannot guarantee that any bank, game or streaming service will accept a modified phone.

Can I install SUSFS without wiping my data?

Installing a helper may not wipe data, but reaching the required bootloader state often does. Bootloader unlocking erases user data by design. Make a tested off-device backup before starting, even if a guide claims your device is already prepared.

How do I remove SUSFS?

Disable the helper first if the manager remains usable. Removing the kernel patches usually requires restoring the exact stock boot or kernel image, or flashing supported firmware. Follow the device-specific recovery process and keep the bootloader unlocked until stock images boot correctly.