# Mountify: A KernelSU Metamodule That Replaces Magic Mount With OverlayFS

> Mountify is a Shell-based module for KernelSU, APatch, and Magisk that mounts module files globally using OverlayFS instead of magic mount. It trades detection resistance for complexity, with two backing modes and a sharp set of caveats.

**backslashxx/mountify** — Globally mounted modules via OverlayFS.

- Repository: https://github.com/backslashxx/mountify
- Stars: 1,447 · Forks: 70
- Language: Shell
- License: Unlicense
- Published: 2026-08-22 · Updated: 2026-08-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/backslashxx-mountify

## What Mountify Solves and Who It Is For

Mountify addresses a specific problem in Android root module management: the traditional magic mount approach creates a large number of mounts, which detection tools like Zimperium can spot. The README states that magic mount drastically increases mount count, making detection possible. Mountify instead uses OverlayFS to overlay module directories onto system paths, mimicking an OEM mount like /mnt/vendor/my_bigball. The target audience is users of KernelSU, APatch, or Magisk who want a less detectable mounting method and are willing to configure a separate module. It is not for casual users; the README's own tone, calling the module a "shitty band-aid," signals that this is a niche tool for people who understand the underlying mechanics.

## Two Backing Modes: tmpfs and ext4 Sparse

Mountify offers two modes, each with a different trade-off. The tmpfs mode is the default and the main recommendation. It copies the contents of each module directory to a fake folder under /mnt/vendor, mirrors SELinux contexts, and then overlays those folders onto system paths. This mode avoids creating device nodes on /proc/fs, which the README says is a detection vector for OverlayFS with ext4 image upperdirs. The ext4 sparse mode creates an ext4 sparse image, mounts it, copies module contents, and then remounts it before overlaying. The README explicitly says this mode creates ext4 nodes, which can cause detections, and it exists to accommodate things like GPU drivers. This is a fallback, not the primary path.

## Getting It Running: Installation and Basic Configuration

The README does not provide explicit install commands, but it describes a configuration file at /data/adb/mountify/config.sh. After installing the module, you edit this file to change behavior. The default setting, mountify_mounts=2, mounts all modules that have a system folder. To mount only specific modules, set mountify_mounts=1 and edit modules.txt to list the module IDs you want. The README shows an example with module IDs like Adreno_Gpu_Driver and ViPER4Android-RE-Fork. You can set FAKE_MOUNT_NAME="mountify" to customize the fake folder name. For certain modules, set mountify_stop_start=1 to restart Android at service. The WebUI is mentioned as a user-friendly way to edit config, but the README does not describe how to access it.

## Skipping Modules and Unmounting

A notable detail is that Mountify respects the standard skip_mount file on KernelSU and APatch, but on Magisk you must create a file named skip_mountify in the module directory instead. This is a subtle difference that could trip up users moving between root solutions. For unmounting, the README recommends using Zygisk-based tools like NeoZygisk or Zygisk Next, and you must set MOUNT_DEVICE_NAME to "APatch", "KSU", or "magisk" depending on your setup. There is also a mountify_custom_umount option, but the README warns that the Zygisk provider umount is better and the custom method is a second choice. This layered unmount approach adds complexity, but it is a realistic reflection of how Android module mounting works.

## Anti-Bootloop Protection and Expert Mode

The README mentions an anti-bootloop protection that is enabled by default. You can disable it by creating a file named /data/adb/mountify/explicit_I_want_a_bootloop. That filename is blunt and makes the risk clear. There is also mountify_expert_mode=1 to force expert mode, which disables safety checks. These options are for advanced users who know why they need them. The README's warning that it is a "sharp knife" is not rhetorical; the presence of these flags shows that the project anticipates breakage. If you are not comfortable debugging a bootloop, you should not touch these settings.

## Known Limitations and a Concrete Failure Mode

The README lists a specific incompatibility: Mountify fails with De-Bloater because that app uses dummy text instead of proper whiteouts. The author recommends System App Nuker instead, which uses proper whiteouts. This is a concrete failure mode you can verify before adopting the module. Another limitation is that the ext4 sparse mode creates device nodes that can be detected, and the LKM to nuke those nodes is experimental and only works on GKI 5.10+ or KernelSU 22105+. The README also notes that F2FS /data as an overlay source fails with native casefolding, so only sdcardfs users can use /data as an overlay source. These are real constraints, not hypothetical edge cases.

## Alternatives and How They Differ

The primary alternative is the standard magic mount used by Magisk and KernelSU. Magic mount is simpler and does not require OverlayFS kernel support, but it creates many mounts that are detectable. Another alternative is using OverlayFS directly with /data as the overlay source, but the README explains that this is rare because ext4 /data as an overlay source is possible but uncommon, and F2FS fails with casefolding. The standalone script mentioned in the README is a lighter alternative for module developers, but it is a separate tool. The key difference is that Mountify tries to mimic an OEM mount, which is a detection-resistance strategy that other tools do not pursue.

## Maintenance, Upgrade Cost, and Licensing

The repository shows active development with recent releases numbered 202, 203, and 204, all pushed in 2025 and 2026. The last push was 2026-08-25, so the project is not archived. The license is The Unlicense for the main module, which means you can use it freely, but the LKM is under GPLv2 and the WebUI is under MIT. This split licensing is worth noting if you plan to redistribute or modify parts. The README offers no support or warranty, stating "Support / Warranty: None, none at all." The upgrade cost is moderate: you need to track new releases and check whether config keys have changed, but the README does not document a migration path between versions. You should verify each release's changelog before upgrading.

## Conclusion

Adopt Mountify if you run KernelSU, APatch, or Magisk and need a module mounting method that avoids the high mount count of magic mount, and you accept the complexity of OverlayFS. Do not adopt it if you rely on De-Bloater, which does not use proper whiteouts and will fail. Before installing, verify your kernel has CONFIG_OVERLAY_FS=y, and if you use tmpfs mode, confirm CONFIG_TMPFS_XATTR=y. For ext4 sparse mode, check whether your KernelSU version handles the device nodes automatically or you need the experimental LKM. The project is explicit that support is none, so test on a disposable device first.

## FAQ

### What does mountify need to run?

A kernel built with OverlayFS support, which the documentation marks as required, and one built with tmpfs extended attributes, which it marks as highly encouraged. It installs as a metamodule on KernelSU and also works under APatch and Magisk.

### What is the difference between the two mountify modes?

The tmpfs mode copies module contents into the fake vendor folder and overlays them, with the SELinux context of every file mirrored. The ext4 sparse mode does the same inside a sparse ext4 image, then unmounts and remounts that image on the same path so it becomes the overlay upper directory.

### How do I configure mountify?

Through its web interface, or by editing the shell configuration file it installs. By default it mounts every module with a system folder; to mount only selected ones you change the mount-all setting and list the modules you want in a modules file.

### What licence is mountify under?

Three. The module itself is under the Unlicense, the bundled kernel module is under version two of the GNU General Public License, and the web interface is under the MIT licence. Each has its own licence file in the repository.

### Why does mountify conflict with some debloating tools?

Because at least one popular debloating application removes files using dummy text files rather than proper filesystem whiteouts, which this project's mounting approach cannot accommodate. The documentation recommends a different application that uses proper whiteouts instead.

## Sources

- [Official README](https://github.com/backslashxx/mountify#readme)
- [Project repository](https://github.com/backslashxx/mountify)
- [Release notes](https://github.com/backslashxx/mountify/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/backslashxx-mountify