TL;DR: If SUSFS emulate_vold_app_data Android data ENOENT errors make an app’s own files appear missing, set emulate_vold_app_data=0 in SUSFS4KSU, reboot fully, and test again. SUSFS revision 27 can hide package directories when value 2 is selected; ENOENT usually means hidden from that process, not deleted.
By the PrivacyPortal team
Last updated July 2026
The verified fix for this failure is to disable Vold-app-data emulation, reboot, and retest the affected app before clearing data or reinstalling anything. On reported SUSFS r27 and HyperOS 3 configurations, emulate_vold_app_data=2 placed third-party package directories under /sdcard/Android/data into a recursive SUSFS hiding list. The owning app could then receive an ENOENT result—Linux shorthand for “no such file or directory”—when accessing its own media or cache. The files may still exist and remain visible from a different context.
Image caption: A file manager showing an Android/data package directory that appears present outside the affected app.
What causes SUSFS Android/data ENOENT errors?
SUSFS, short for “suspected filesystem”, adds kernel-level mechanisms for hiding filesystem evidence associated with root and system modifications. SUSFS4KSU supplies the userspace configuration layer used with a compatible, SUSFS-patched KernelSU kernel.
Revision 27 gives emulate_vold_app_data three materially different behaviours:
| Value | Revision 27 behaviour | Likely effect |
|---|---|---|
| 0 | Vold-app-data emulation is disabled | Package directories are not automatically added by this feature |
| 1 | Uses add_sus_path for third-party package directories | Applies ordinary SUSFS path hiding |
| 2 | Uses add_sus_path_loop for third-party package directories | Can hide package paths recursively and trigger ENOENT |
With value 2, each applicable directory below /sdcard/Android/data can be marked through add_sus_path_loop. SUSFS deliberately makes a marked path look absent to an affected process. That is why Telegram clients, forum clients and other applications may lose media, downloads or cache access even though storage has not been physically erased.
SUSFS4KSU revision 27 maps emulate_vold_app_data=2 to add_sus_path_loop for third-party packages under /sdcard/Android/data.
Why “missing” does not necessarily mean deleted
Android applications access files under a process identity called a UID. Filesystem results can differ according to that UID, mount namespace and kernel filtering. A file manager running in one context may see a directory while the application that owns it receives ENOENT.
This distinction matters because destructive troubleshooting can turn a reversible visibility problem into real data loss. Do not clear the app’s storage, uninstall it, format shared storage or delete the package directory merely because an error says the path does not exist.
Android’s scoped-storage rules also restrict which app-specific directories a process may inspect. The official Android 11 storage documentation explains that applications cannot access other applications’ app-specific external-storage directories. SUSFS adds another filtering layer, so results from a root shell, file manager and ordinary app are not directly interchangeable.
A useful diagnostic pattern is:
- The app worked before SUSFS or a SUSFS4KSU configuration change.
- Only media, downloads or cache under /sdcard/Android/data/<package> fail.
- Logs show ENOENT rather than a permission-denied result.
- The package directory is visible from another trusted context.
- Normal access returns after disabling the emulation and rebooting.
Before changing SUSFS settings
Back up first. Copy irreplaceable photographs, documents, authenticator recovery codes and application exports to storage that is not being modified. Confirm that the backup opens on another device or computer. A directory that is currently hidden from one process can still be damaged by an unrelated mistake.
This fix does not require unlocking the bootloader. If your device is not already rooted with a compatible setup, do not unlock or flash it solely to test this guide. Bootloader unlocking normally performs a factory reset and wipes user data. Flashing the wrong boot or init_boot image can leave a device unable to start.
Rooting and custom kernels can also affect:
- warranty or manufacturer support;
- over-the-air updates and boot-image compatibility;
- device security if root access or modules are poorly controlled;
- Play Integrity results and applications that perform their own checks;
- banking, workplace, streaming and contactless-payment applications.
No SUSFS configuration can be promised to satisfy a particular bank or application. Detection changes frequently, and an app may use checks unrelated to filesystem hiding. PrivacyPortal’s Android bootloader unlocking guide explains the wipe and recovery implications for readers still deciding whether modification is appropriate.
How to fix SUSFS emulate_vold_app_data Android data ENOENT
These steps apply to a device already using KernelSU or KernelSU Next, a kernel patched for the matching SUSFS implementation, and the compatible SUSFS4KSU userspace module. Use the module build supplied for your kernel and SUSFS revision; mixing incompatible releases can create different failures.
- Back up the affected app. Use the app’s own export or synchronisation feature where available. Copy accessible shared files elsewhere, but do not delete the original package directory.
- Record the current environment. Note the ROM and build, Android version, kernel version, KernelSU variant and version, SUSFS kernel revision, and SUSFS4KSU module revision. The known report involved SUSFS r27 on HyperOS 3, so these details are important when comparing results.
- Confirm the symptom. Reproduce one simple failure, such as opening an existing media item or creating a disposable cache file. Record the exact package name and path. Avoid repeated tests that overwrite important data.
- Open SUSFS4KSU settings. In your KernelSU manager, open the installed SUSFS4KSU module’s WebUI or the matching Custom SUSFS Settings interface. If the interface says SusFS not supported, stop: the running kernel does not expose the support expected by that module, or the kernel and userspace components do not match.
- Find Vold-app-data emulation. Locate the setting labelled emulate_vold_app_data or its equivalent Vold app-data emulation control. Take a screenshot of the original state so it can be restored deliberately.
- Set the value to 0. Disable the feature or enter emulate_vold_app_data=0, then apply or save the configuration. Do not compensate by adding broad Android storage paths to /data/adb/susfs4ksu/sus_path.txt; an overly broad path rule can reproduce the same visibility problem.
- Perform a full reboot. Force-stopping the application is insufficient because kernel-level path state and mount-related configuration may persist until boot. Wait for Android to finish starting before testing.
- Verify from the affected app. Repeat the same read or write operation used in step 3. Check existing media, create a disposable file if the app permits it, close the app, reopen it and confirm the file remains accessible.
- Review logs if the failure remains. Capture the app error and relevant system or module logs without posting personal filenames, tokens or account details. If ENOENT persists with the setting disabled, investigate ROM-specific FUSE behaviour, scoped storage, permissions and module conflicts rather than repeatedly changing unrelated hiding options.
The “Modules, apps & files to try” section supplied with this guide should be used to obtain the named SUSFS4KSU component. Match it to the project and kernel instructions; do not install a similarly named archive from an unverified repost.
Image caption: The SUSFS4KSU settings screen with Vold-app-data emulation changed from value 2 to value 0.
How to verify the fix without misreading the result
A successful result is not merely that a file manager can browse the directory. The affected application itself must regain stable access after reboot.
| Test | Useful result | What it tells you |
|---|---|---|
| Open existing app media | The item loads normally | The owning app can resolve and read its path |
| Create disposable content | The app saves it without ENOENT | Write-path resolution is restored |
| Restart the app | The new item remains available | The result was not only an in-memory success |
| Reboot once more | Access remains stable | The saved configuration survives boot |
If access returns only after emulate_vold_app_data=0, the result strongly implicates the emulation path. It does not prove that SUSFS alone contains the underlying defect. HyperOS 3’s FUSE-based storage layer may contribute, and other ROMs or kernels can behave differently.
In the reported HyperOS 3 and SUSFS r27 case, disabling emulate_vold_app_data and rebooting restored app storage access, although a FUSE interaction was not ruled out.
Common pitfalls and conflicting modules
Clearing app data too early
Clearing data creates genuine loss and removes evidence needed to diagnose the visibility issue. Disable the emulation, reboot and retest before considering any reset.
Assuming kernel support installs the module
A SUSFS-patched kernel and the SUSFS4KSU userspace module perform different jobs. Kernel support alone does not provide the expected WebUI and configuration layer. Conversely, installing the module cannot add missing kernel support.
Mixing incompatible SUSFS revisions
Kernel patches, headers and userspace tooling must agree. Build errors involving susfs_sus_path_by_filename or SYSCALL_FAMILY_ALL_ENOENT often indicate mismatched patch generations or missing headers. Do not mix SUSFS 1.4 kernel changes with 1.5 userspace components, or vice versa.
Adding broad entries to sus_path.txt
The path list at /data/adb/susfs4ksu/sus_path.txt is powerful. Adding shared-storage roots, package-parent paths or unrelated system overlays can hide more than intended. Change one variable at a time and retain a recoverable copy of the previous configuration.
Stacking multiple hiding systems
Integrity Box and other modules may add paths automatically during post-mount. Community reports describe conflicts between some Integrity Box releases and recent SUSFS4KSU configurations. A minimal stack is easier to diagnose than several modules attempting to hide or rewrite the same paths.
The official KernelSU architecture guide is useful for understanding why a kernel-integrated root design behaves differently from a userspace-only module. Readers reviewing their broader setup may also find PrivacyPortal’s practical guide to de-Googling Android helpful.
Image caption: A troubleshooting flow comparing application access before and after disabling emulate_vold_app_data and rebooting.
A practical decision framework
- Access returns after value 0 and reboot: leave Vold-app-data emulation disabled unless a later, device-tested release explicitly resolves the behaviour.
- The module reports no SUSFS support: verify the running kernel and module compatibility; changing app permissions will not add kernel support.
- ENOENT remains with value 0: inspect custom SUSFS path entries, automatic post-mount rules, scoped-storage behaviour and ROM-specific FUSE issues.
- The error becomes permission denied: investigate Android permissions and scoped storage separately; EACCES and ENOENT describe different failure modes.
- The device bootloops after another change: use the recovery method documented for your root manager or restore the known-good boot image. Do not flash an image from another device or build.
Frequently asked questions
Does ENOENT mean my Android/data files were deleted?
No. ENOENT means the requesting process was told that the path does not exist. With SUSFS, that can be an intentional filtered view. Confirm from a trusted alternative context and disable emulate_vold_app_data before taking destructive action.
Should I use emulate_vold_app_data=1 instead?
Value 1 uses add_sus_path rather than the recursive add_sus_path_loop used by value 2 in revision 27. For diagnosing broken app storage, the verified baseline is value 0. Test other modes only when you understand the device-specific trade-off and have a backup.
Can SUSFS be installed as an ordinary Magisk module?
SUSFS requires compatible kernel changes; the userspace module does not create those changes by itself. SUSFS4KSU is designed around KernelSU-family setups with kernel support. Do not assume a Magisk installation can gain SUSFS merely by flashing the module archive.
Will disabling this option break Play Integrity or banking apps?
It may change filesystem-hiding behaviour, but no universal outcome can be guaranteed. Play Integrity and individual applications use multiple signals, and banks can change their checks without notice. Test only on your own device and keep a reliable recovery path.
Why does the problem continue after I change the setting?
A full reboot may be required. If the saved value is definitely 0 after reboot, inspect custom path rules, conflicting modules, application permissions, scoped storage and the ROM’s FUSE implementation. The verified HyperOS 3 report does not establish that every ENOENT failure has the same cause.
Can I delete and recreate the package directory?
That should not be the first response. Deletion risks losing real application data and may not change the filtered view seen by the app. Back up, disable the emulation, reboot and verify access first.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
