SUSFS: How to Hide Mounts with sus_mount

TL;DR: Modern susfs does not hide an arbitrary path with the old add_sus_mount command. SUSFS 2.x detects KernelSU-created mounts, then hides them from non-root processes. Per-path removal now belongs to KernelSU’s kernel-umount feature. You need a compatible patched kernel, a trusted userspace module where required, careful app profiles, and a full backup.

By the PrivacyPortal team

Last updated 29 July 2026

If you searched for a sus_mount guide, the key detail is that older instructions are now out of date. Current SUSFS handles KernelSU mounts automatically through the kernel. It can hide those mounts from processes without root access. It cannot make an unlocked phone identical to a stock, locked device. It also cannot guarantee that banking, media or work apps will run. Their checks change without notice. This guide explains the current method, the files involved and how to test the result safely.

What susfs and sus_mount mean in 2026

SUSFS is a set of Linux kernel changes designed for rooted Android devices. It changes what selected processes can see through filesystem and kernel interfaces. The name is short for “SUS filesystem”, although it covers more than one filesystem feature.

The kernel patch does the real work. A userspace susfs module supplies scripts, settings and integration with a root manager. Installing only that module does not add missing kernel code.

The term sus_mount usually refers to SUSFS mount hiding. Older releases accepted paths through add_sus_mount. That command is now a legacy interface.

The upstream SUSFS project deprecated the path-level add_sus_mount command on 22 November 2025.

SUSFS 2.x instead identifies mounts created by KernelSU. Its hide_sus_mnts_for_non_su_procs control hides those mounts from non-root processes. KernelSU’s kernel-umount feature handles cases where a path must be removed from a process namespace.

Caption: The current design separates automatic mount hiding from per-app kernel unmount rules.

How the current mount-hiding path works

Android apps normally run with separate user IDs and without root. KernelSU also gives processes individual root permissions through app profiles. SUSFS uses that distinction when deciding which mount details to expose.

For a normal app, the kernel can filter KernelSU-related mounts from views such as mount information. A process with granted root may still need the real view. This is why app profiles matter as much as the module switch.

Mount hiding and kernel unmounting solve related but different problems:

• Automatic hiding: SUSFS filters recognised KernelSU-created mounts for non-root processes.
• Kernel unmount: KernelSU removes selected mounts from a chosen app’s mount namespace.
• Path hiding: Other SUSFS features can filter selected paths or kernel details where supported.

These controls reduce exposed rooting artefacts. They do not relock the bootloader, restore verified boot or undo changes to the system’s trust state.

Choose the right stack before installing

Current root setup	SUSFS position	Practical choice
KernelSU Next or SukiSU Ultra with a SUSFS-patched kernel	Kernel support may already be integrated	Check the manager and kernel notes. Add the trusted userspace module only if the build requires it.
Standard KernelSU	Support depends on the exact kernel build	Use a kernel built for the device with matching SUSFS patches. Then use a compatible module.
APatch	Support is branch-specific	Use only an APatch-compatible implementation documented by its maintainer.
Magisk	A module alone cannot provide SUSFS kernel support	Keep to a supported Magisk hiding stack, or change kernels and root architecture deliberately.
Stock, unrooted Android	SUSFS is not applicable	Keep the bootloader locked unless there is a clear reason to modify the device.

Do not flash a kernel because its filename merely contains “SUSFS”. It must match the phone, Android release and expected boot image layout.

How to install and use susfs for KernelSU

This numbered process covers a compatible KernelSU-based device and keeps risky changes easy to reverse.

1. Back up photos, messages, authenticator recovery codes and app data to a separate device or encrypted store.
2. Confirm that your exact device build has a maintained KernelSU or KernelSU Next kernel with SUSFS support.
3. Read the kernel’s release notes. Save the stock boot-related images and the known recovery procedure before flashing.
4. Unlock the bootloader only if required. Unlocking wipes the phone, so complete the backup first.
5. Install the compatible kernel by its maintainer’s stated method. Do not reuse commands from another device.
6. Boot Android and confirm that KernelSU Manager works before adding any module.
7. Get sidex15’s susfs4ksu-module from the verified files section attached to this article. Check its source and release details.
8. Install the module through the manager’s Modules page when your kernel or manager documentation requires it. Then reboot.
9. Open the module’s settings or WebUI. Enable hiding for non-root processes and leave logging off during normal use.
10. Deny root to the app being tested. Reboot, verify SUSFS status, then inspect mount visibility before testing apps.

Prerequisites and files you need

You need an unlockable device, a matching patched kernel and a supported KernelSU-family manager. You also need a computer with working platform tools if recovery requires fastboot.

Use sidex15’s susfs4ksu-module when the kernel or manager documentation calls for its userspace layer. The “Modules, apps & files to try” section provides the verified file entry. Do not download a renamed copy from a chat attachment.

The sidex15 susfs4ksu-module project released v1.5.2+ Revision 28 on 26 July 2026.

Keep the module, kernel and manager versions recorded together. That small note makes rollback much easier after an update.

How to verify that SUSFS is active

First check the module or manager status page. It should report working kernel support. An error such as “susfs not found” means the userspace module cannot reach a compatible kernel implementation.

Next connect through Android Debug Bridge without running su. Use adb shell cat /proc/self/mountinfo and inspect the visible mounts. Compare that result with a deliberate root shell only if you understand the extra access. A non-root process should not see the KernelSU module mounts which SUSFS recognises.

Also check that the test app has no root grant. Root-enabled apps can receive a different view by design.

Play Integrity is not a reliable SUSFS status test. It combines device, account and server-side signals. A pass or failure does not prove whether mount filtering works.

What the module settings actually change

Start with the smallest useful configuration. Enable mount hiding for non-root processes, keep SUSFS logs disabled during daily use and reboot after a material change.

Some interfaces offer kernel version spoofing. This can remove a visible “KSU” string from the reported kernel version. It does not replace a clean, compatible kernel. Record the original value before using it.

Only enable “spoof on boot” after a manual setting survives one clean restart. A bad persistent value is harder to diagnose than a temporary one.

The “make it sus” action in some SUSFS front ends applies a group of hiding settings. Review its listed changes first. Labels and defaults can vary between module revisions.

Current upstream GKI branches identify their kernel module template as SUSFS v2.2.0 as of 29 July 2026.

A module release number and the kernel patch version describe different layers. Seeing v1.5.2+ for userspace and v2.2.0 for kernel support is not an error.

Caption: A healthy setup reports both the userspace module revision and compatible kernel-side SUSFS support.

Common failure modes and practical fixes

The installer says “susfs not found”

This usually means the running kernel lacks compatible SUSFS support. It can also indicate a mismatch between the kernel patch and module revision.

Do not keep reinstalling the same ZIP. Confirm the running kernel name, SUSFS version and manager family. Then compare them with the maintainer’s compatibility notes.

The phone bootloops after a kernel change

A bootloop often points to the wrong kernel build, boot image layout or Android release. Stop experimenting and follow the device maintainer’s recovery process.

Restore the saved stock image only through commands verified for that device. A/B devices, vendor boot images and init boot images are not interchangeable.

The official Android bootloader locking and unlocking documentation explains why unlocking resets user data. Do not relock a modified device unless its complete firmware is known to support relocking.

Modules disappear from the manager

A conflicting mount-hiding setup can make module paths invisible to the manager itself. Disable the newest change from recovery or the manager’s safe mode where supported.

A developer-setting command sometimes appears in community fixes. Do not paste it blindly. Check the exact module documentation because the command and effect can change.

An app still detects the modified device

Check whether the app has root permission. Then check its kernel-umount profile and restart the app process. A full reboot gives the cleanest test.

The app may also inspect bootloader state, verified boot, installed packages, hardware attestation or server history. SUSFS only addresses part of that surface. Never assume a bank will accept a modified phone.

Conflicts to avoid

Do not stack several tools that alter the same mounts or process views. Overlapping hooks can expose more information, break module mounting or cause a boot failure.

Community reports often flag conflicts between SUSFS configurations and tools such as Shamiko, NoHello, TreatWheel or Zygisk Assistant. Compatibility depends on the root manager and release. Follow the current module maintainer’s exclusions.

A cautious test order is:

• Confirm the patched kernel boots with no extra modules.
• Confirm the root manager can grant and revoke root.
• Add the required SUSFS userspace module.
• Test mount visibility with all optional hiding modules disabled.
• Add one optional component at a time, with a reboot between changes.

This order gives each failure a likely cause. It also makes safe mode or manual module removal more useful.

Security, updates and rollback

Root access expands the impact of a malicious module. A module can run commands at boot, read protected data or leave the phone unusable. Only install releases from a maintainer’s official repository. Review scripts where practical.

Never treat a familiar module.prop name as proof of origin. An attacker can copy a module name and icon while replacing its service scripts.

Over-the-air updates can replace the patched kernel. They may remove SUSFS support or leave the userspace module unable to load. Disable automatic installation if your device workflow requires manual kernel handling.

Before each update, keep:

• A fresh data backup and separate recovery codes.
• The stock boot-related images for the installed firmware.
• The last working kernel and module files.
• Written fastboot or recovery steps for the exact device.

Unlocking may affect warranty support. Root can also weaken parts of Android’s security model. Readers who want privacy without ongoing maintenance may prefer a supported, de-Googled system. Our guide to de-Googled Android phones explains that lower-risk route.

Caption: Keep stock images, the last working kernel and recovery instructions together before changing the boot chain.

A simple decision framework

Use SUSFS only when all four answers are yes:

• Compatibility: Is there a maintained patched kernel for this exact device and Android build?
• Recovery: Can you restore the phone if it stops booting?
• Trust: Can you verify the source of every kernel, manager and module?
• Need: Does your use case require KernelSU mount filtering?

Stop if any answer is no. A hidden root setup is not worth losing data or weakening a stable phone without a clear benefit.

Experienced flashers should also separate testing from daily use. Test a new kernel and module pair before restoring sensitive accounts. Curious beginners may find our Android bootloader and rooting guide useful before changing the kernel.

Frequently asked questions

Does susfs work without a patched kernel?

No. The kernel patch provides the filtering features. A susfs module cannot add them to an unsupported running kernel. The usual result is a “susfs not found” error or settings that have no effect.

Do I still need the SUSFS module with KernelSU Next?

It depends on the kernel and manager build. Some KernelSU Next or SukiSU Ultra packages integrate the required support and controls. Others still expect sidex15’s userspace module. Follow the kernel maintainer’s release notes rather than installing it by default.

What replaced add_sus_mount?

SUSFS 2.x automatically identifies KernelSU-created mounts. The hide_sus_mnts_for_non_su_procs control filters them for processes without root. KernelSU’s kernel-umount mechanism now handles per-path removal for selected app profiles.

Will SUSFS make banking apps work?

There is no guarantee. Banking apps can use Play Integrity, hardware attestation, boot state, package checks and their own server rules. A method that works today may fail after an app or server update.

Can SUSFS restore a locked boot state?

No. SUSFS may filter some reported details, but it does not cryptographically relock the bootloader. It cannot restore the original verified boot trust chain on a modified device.

Is susfs kernelsu support safe for beginners?

It carries real risk because it needs kernel-level changes. Beginners should only proceed with exact device support, complete backups and a tested recovery path. Unlocking the bootloader wipes all user data.

Why did SUSFS stop working after an OTA update?

The update may have replaced the patched kernel. Confirm the running kernel and SUSFS status before reinstalling any module. Use a new compatible kernel built for the updated firmware, not the previous boot image.