TL;DR: How to use susfs safely means using a KernelSU-compatible phone with a kernel that was built with matching SUSFS patches, then installing the matching userspace helper and checking that it reports support. A module alone cannot add SUSFS. Back up first: bootloader unlocking wipes data, and kernel changes can affect booting, updates, app checks, and device security.
By the PrivacyPortal team
Last updated August 2026
SUSFS is an experimental filesystem-hiding feature for rooted Android setups. It works in the kernel, which is the core software beneath Android. That is why the answer to how to use susfs starts with kernel support, not an app download. If your running kernel lacks the right patches, a SUSFS module cannot switch the feature on.
In practice, SUSFS is mainly used with KernelSU and KernelSU Next. It can reduce visible traces of root-related files for selected apps. It does not make a device “undetectable”. Banking apps, games, work profiles, Play Integrity, and device-management tools use their own checks. Never rely on any root setup to pass a particular app.
Image caption: A rooted Android phone connected to a computer, with backup and boot image files clearly separated before any flashing work.
What SUSFS is, and what it is not
SUSFS means “SUS File System”. It is a set of kernel patches that can hide configured filesystem paths or mount information from selected processes. This gives it a different role from ordinary root-hiding modules. Those modules run in userspace, while SUSFS needs support in the kernel that is already running on your phone.
The usual stack has three parts: an unlocked phone, a KernelSU or KernelSU Next root setup, and a kernel or boot image built with matching SUSFS support. A userspace module then provides controls and additional configuration.
The research brief for this guide was checked on 27 August 2026: installing a userspace module alone cannot add SUSFS support to a kernel.
SUSFS is not a universal Magisk feature. Current public workflows focus on KernelSU-family setups. Installing a SUSFS-related ZIP in Magisk does not patch the kernel for you. Treat any guide that claims otherwise with care.
Decide whether SUSFS suits your device
Use SUSFS only if you understand how you will recover from a failed boot. A known-good stock boot image, a working fastboot connection, and a current backup matter more than a clever module stack.
| Situation | Best next step | Why |
|---|---|---|
| Stock kernel with no SUSFS build | Do not install the helper yet | The helper cannot create kernel support. |
| KernelSU kernel advertised with matching SUSFS support | Check the maintainer’s build notes and version match | Patch and helper versions must agree. |
| KernelSU Next with built-in SUSFS | Confirm support in the manager or module interface | Some builds include it, but names and controls vary. |
| Magisk-only root setup | Keep your current setup or change root method deliberately | SUSFS is not enabled by a Magisk module alone. |
| Phone used for payments or work | Test on a spare device first | Root and an unlocked bootloader may break access regardless of SUSFS. |
Kernel builds must also match your exact device, Android release, security patch level, and kernel branch. A boot image for a similar model can still brick your phone. If a maintainer does not state those matches clearly, stop and ask before flashing.
Risks to understand before you start
Back up your photos, authenticator recovery codes, files, messages, and any keys stored only on the phone. Bootloader unlocking normally wipes user data. Flashing the wrong boot or init_boot image can cause a boot loop, loss of Wi-Fi, broken cameras, or a device that needs fastboot recovery.
- An unlocked bootloader reduces physical security and may affect warranty support.
- Over-the-air updates may fail, overwrite your modified image, or require manual recovery.
- Root can break banking, streaming, game, work, and security apps.
- Hiding root paths does not remove every root signal or guarantee app access.
- Mixing old and new SUSFS components can produce confusing errors or instability.
Download files only from the relevant project maintainer or your device kernel maintainer. Verify hashes when they are supplied. Keep a copy of the original boot or init_boot image in a safe place outside the phone.
Image caption: A recovery checklist showing a verified device codename, matching Android build, original boot image, and a tested fastboot connection.
How to use susfs with KernelSU
These steps describe the safe order for a user-owned phone with a known compatible KernelSU or KernelSU Next kernel.
- Back up all important data and save the matching stock boot or init_boot image on your computer.
- Confirm your exact device codename, Android build, kernel version, and active slot if your device uses A/B partitions.
- Unlock the bootloader only if you accept the data wipe and the related security and warranty effects.
- Install KernelSU or KernelSU Next using the method documented for your exact device and Android build.
- Flash only a kernel, boot image, or init_boot image whose maintainer confirms matching SUSFS support.
- Boot Android fully and confirm that root works before adding any SUSFS helper.
- Install the matching SUSFS4KSU userspace module from the “Modules, apps & files to try” section.
- Reboot, open the module interface, and check whether it reports SUSFS support.
- Enable only the minimum settings you need, then reboot and test normal phone use first.
- Test one app at a time and keep a recovery path ready before changing more paths or modules.
Prerequisites for a successful install
Start with a compatible kernel, not merely a compatible phone. The SUSFS patch generation and the userspace helper must match. Do not mix SUSFS 1.4 kernel patches with a 1.5-oriented userspace setup, for example. Mismatches can lead to failed builds, missing functions, or settings that appear to apply but do nothing.
KernelSU Next is commonly paired with SUSFS because both work close to the kernel. Some kernels ship SUSFS support already. Others require a separately built SUSFS-enabled kernel. Read the release notes for your precise build rather than copying settings from another device.
How to verify that SUSFS actually works
A “SUSFS not supported” message means the running kernel does not expose the required support. Recheck the flashed image, device slot, and module compatibility. Do not add more hiding modules in an attempt to fix it.
After a reboot, confirm basic functions first: calls, mobile data, Wi-Fi, Bluetooth, camera, charging, and biometrics. Then test the selected app. If it fails, remove recent changes one at a time. The relevant path configuration is commonly stored under /data/adb/susfs4ksu/, but file names and controls can differ by module release.
SUSFS support is a property of the running kernel, not proof that every app will accept a rooted device.
Configure SUSFS with the smallest possible rule set
The best SUSFS configuration is usually the least complex one. Start from module defaults. Enable a setting only when you can explain what it changes and how to undo it. Broad path hiding can break Android components, module updates, or app rendering.
Many KernelSU users configure the SUSFS4KSU interface to reduce logging, spoof a kernel version string where their supported build offers that option, and apply settings at boot. Labels can change between releases. Follow the current module documentation rather than relying on screenshots from old guides.
Be especially careful with custom path lists. Community reports show that hiding system overlay idmap paths can cause a horizontal display fault on some LineageOS-based builds. A path that is harmless on one ROM may be needed by another ROM.
Modules that can conflict with SUSFS
Do not pile several hiding tools onto the same device. Tools such as Shamiko, NoHello, Treat Wheel, Zygisk Assistant, Integrity Box, ReZygisk, and Zygisk Next can overlap or conflict depending on the root stack. Their names do not guarantee compatibility.
Integrity Box has been reported to add custom ROM paths aggressively in some configurations. That can undermine a carefully limited SUSFS path set. If you troubleshoot a failure, disable optional hiding modules first. Add them back only after confirming that each one has a clear purpose.
In community testing, a SUSFS module may fail with “susfs not found” when the kernel itself lacks matching SUSFS support.
Common SUSFS problems and sensible fixes
The module says “SUSFS not supported”
This is usually a kernel issue. Confirm that the device booted the intended image and correct slot. Check the kernel maintainer’s notes for your exact Android build. Reflashing a module will not add missing kernel patches.
The phone boot loops after flashing
Stop changing settings. Boot recovery or fastboot, then restore the known-good stock image or previous working image for your exact device. A boot loop is a recovery task, not a reason to try more modules.
An app still detects root or an unlocked device
This outcome is normal. App checks can inspect bootloader state, hardware-backed attestation, ROM signatures, debug state, installed packages, or behaviour. SUSFS addresses selected filesystem visibility. It cannot promise a result against any bank, wallet, game, employer tool, or service.
An OTA update fails or root disappears
Modified boot-chain components often complicate updates. Read your ROM and root manager instructions before accepting an OTA. You may need to restore, update, patch the new image, and reapply your setup. Keep your backup images until the updated device is stable.
When SUSFS is the wrong tool
If your goal is simply a private daily phone, rooting may add more risk than benefit. A well-supported privacy-focused Android build can reduce data collection without modifying the boot chain. PrivacyPortal’s guide to de-Googled Android phones explains the trade-offs in plain terms.
If you need a specific app for work, travel, payments, or two-factor authentication, keep an unmodified fallback device or use the service’s supported route. Do not turn a critical phone into a testing platform.
For users who want a device prepared with privacy in mind but do not want to flash kernels, a privacy-first Android phone from PrivacyPortal may be the calmer option. It does not remove the need to assess app compatibility, but it avoids making SUSFS a daily requirement.
Image caption: A simple decision view showing when to use a supported SUSFS kernel, when to keep stock software, and when to use a separate test phone.
Frequently asked questions
Can I install SUSFS as a normal Magisk module?
No. A userspace module cannot add the required kernel code. Current SUSFS workflows are focused on compatible KernelSU and KernelSU Next kernels. A Magisk-only setup does not gain SUSFS kernel support by installing a ZIP.
Do I need both a SUSFS kernel and SUSFS4KSU?
You always need a compatible SUSFS-enabled kernel. Some builds also need the SUSFS4KSU helper for configuration or additional functions. Follow the notes for your kernel and module release. If the kernel includes support but the helper says it cannot find SUSFS, check version compatibility.
Will SUSFS make banking apps work?
No method can promise that. SUSFS may hide selected filesystem traces, but apps can use many other checks. Your bank can change its checks without notice. Keep another approved way to access important services.
Does using SUSFS require an unlocked bootloader?
Usually, yes, because installing a custom boot-chain component normally requires bootloader unlocking. Unlocking commonly wipes the phone. Check your manufacturer’s official unlocking information before you begin.
Is SUSFS safe for a daily driver?
It can be stable on a well-maintained, exact-match kernel. It is still experimental modification work. Stability depends on the device, kernel, Android release, modules, and your settings. Test carefully and retain a recovery image.
Where can I check the current project instructions?
Read the SUSFS4KSU project repository and the documentation for your selected KernelSU build. For bootloader concepts and device security, consult Android’s Verified Boot documentation.
Modules, apps & files to try
Use the verified downloads appended to this page for SUSFS4KSU and any compatible KernelSU tools. Choose a file only after matching it to your device, Android build, kernel version, and root manager. Downloading the latest file is not the same as downloading the right file.
That is the practical answer to how to use susfs: start with a matching kernel, add the compatible helper only when needed, use a minimal configuration, and test cautiously. For more root safety basics, see our Android rooting safety guide.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
