meta-magic_mount-rs: systemless mounts for KernelSU and APatch

A metamodule, which is a specific thing in the root ecosystem

Magic Mount Metamodule is an implementation of a metamodule using Magic Mount, based on MKSU, with the template taken from meta-overlay. In the vocabulary of rooted Android, a metamodule is a module that other modules build on: it does not do a job of its own so much as it provides a mechanism that other modules use.

That is what this one provides. It performs systemless modifications, meaning files are overlaid onto the system partition at mount time rather than being written to the partition itself, so a change can be removed by unmounting or rebooting without leaving anything behind. The mechanism it reimplements comes from KernelSU, and the README credits 5ec1cff/KernelSU as the original implementation.

The project is written in Rust, with the crate named magic_mount_rs at version 4.0.12, edition 2024, licensed GPL-3.0, and it declares a workspace with an xtask member. The repository is under Tools-cx-app, the primary language recorded for it is Vue because of the web interface, and the last push was on 2026-10-18. Releases are frequent: v4.0.12 on 2026-10-16, v4.0.11 on 2026-10-02 and v4.0.10 on 2026-09-25.

One line in the README sets expectations honestly, and it is worth reading before you plan around the project: the author says updates will slow down for academic reasons.

The configuration is a small TOML file with four fields

The configuration lives at a fixed path on the device, /data/adb/magic_mount/config.toml, and the default content is short:

mountsource = "KSU"
umount = false
partitions = []
extra_mount = []

Four fields, and each one controls a specific behaviour.

mountsource is the identifier for the systemless mount source, and its default of KSU keeps it consistent with KernelSU behaviour. umount is a boolean that asks whether an unmount should be attempted, and it depends on the KernelSU unmount capability being present. partitions is a list of the specific partitions to operate on systemlessly, with the examples given being mi_ext and my_stock, the kind of vendor partition names that ship on Xiaomi devices.

extra_mount defaults to an empty list, and it is the field with the most detailed rules. An entry such as extra_mount = ["my_product"] merges the contents of the module's top level my_product/ directory into /my_product/, and it explicitly does not read from the module's system/my_product/ path. Two preconditions are stated: the target directory has to exist already, and /system/my_product must have no directory entries at all, including dangling symlinks.

Only single-level partition names are allowed, not paths, and invalid entries are logged and skipped. Modules with no system/ directory are still supported and still follow the disable, remove and skip_mount markers. The configuration takes effect after a restart, and it can also be edited from the web interface, which the README recommends and which offers an extra mount partition editor in both the MiuiX and MD3 themes, supporting adding and removing partition names, again taking effect after a restart.

The custom rules file adds ignore, bind and include

Beyond the TOML configuration there is a separate rules file at /data/adb/magic_mount/custom, whose syntax is a small set of directives. The first verb, ignore, skips a source file from a module. The second, bind, mounts a source read-only onto a target, and the example in the documentation shows that the paths may contain spaces when quoted. The third pair, file and add, both include other rule files recursively, and the two spellings mean the same thing.

There are three verbs. ignore skips a source file from a module. bind mounts a source read-only onto a target, and the example shows that the paths may contain spaces when quoted. file and add both include other rule files recursively, and the two spellings mean the same thing.

The syntax rules are worth knowing. Single quotes, double quotes, paths containing whitespace and end-of-line comments are all supported, and control characters are filtered out. Recursive includes use an independent visited set, which means a circular reference will not recurse infinitely.

The safety rules on bind targets are stricter than the rest. The target must be an absolute path and it cannot contain .. . If the target does not exist, the program constructs a temporary mirror from the nearest existing non-root ancestor, and any remount or registration failure triggers a detach and a rollback. So a bind either lands correctly or leaves the filesystem as it was, which is the right behaviour for something that runs at boot.

Building it needs a Rust nightly, the NDK and a frontend toolchain

The development section lists the dependencies, and they are a mix of a Rust Android toolchain and a web build.

You need a Rust nightly toolchain, the Android NDK, cargo-ndk, Node.js with npm, and pnpm and vite as the dependency and frontend tooling for the web interface. The NDK is located through two environment variables:

export ANDROID_NDK_HOME=<path/to/ndk>
export ANDROID_NDK_ROOT=$ANDROID_NDK_HOME

The build itself is a single cargo command:

cargo xtask build

And the artefact lands in output/magic_mount_rs-*.zip, which is the zip you flash as a module.

The Cargo manifest explains a few of the choices. The package uses cargo-features = ["codegen-backend"], and the dev profile sets codegen-backend to cranelift, so the development build uses that backend rather than the default. The release profile turns off overflow checks, sets codegen-units to 1, uses fat link time optimisation, optimises for level 3 and strips the binary, which is the profile you want for something that runs at every boot on a phone. The workspace lints deny disallowed types outright.

The runtime dependencies are a fairly tight set: rustix with its fs and mount features, libc, clap with derive for the command line, serde with derive, serde_json and toml, thiserror, regex-lite, tempfile, java-properties and encoding_rs, plus rustc-hash, const_format, hex and parking_lot. On Android the crate pulls in android_logger, and off Android it pulls in env_logger, so the same binary can be run on a development machine.

The repository layout also has a module/ directory, a module.yaml, a webui/ directory, an xtask/ directory, a docs/ directory, an update/ directory, tests/, a build.rs and a rust-toolchain.toml.

Where this sits against the KernelSU implementation it replaces

The alternative to this project is the mount mechanism that ships with KernelSU itself, or with APatch, which is what the module is intended to work alongside.

The difference in approach is the language and the packaging. The original implementation, credited in the acknowledgements, lives inside KernelSU as Rust code in the userspace component, and this project takes that mechanism and repackages it as a standalone metamodule with its own configuration file, its own rules file and its own web interface. You can keep KernelSU as your root framework and install this as the module that provides the mounting, or you can use the module's configuration to control mounts that the built-in implementation does not expose, most obviously the extra_mount handling of top level partition directories.

There is also a plain alternative that is worth naming for anyone who only needs one file changed. If the goal is a single system file, a module with that file in its system/ directory and the framework's ordinary overlay does the job, with no configuration and no rules file at all. The metamodule route earns its complexity when you need several partitions, custom binds, or mounts that have to be described declaratively rather than shipped as a directory tree.

What you give up by choosing this one is upstream integration. The KernelSU implementation is reviewed and shipped with the framework, while this is a separate project with a single author, an academic slowdown in updates, and a version scheme of its own at 4.0.12. The mount mechanism it reimplements is a moving target in KernelSU, so a version of this module and a version of KernelSU have to be matched in practice even though nothing in the manifests enforces it.

Editorial conclusion

Adopt meta-magic_mount-rs if you run KernelSU or APatch on Android and need systemless mounts that your current implementation does not give you, especially for extra partition directories outside the system tree, and you are comfortable building Rust code for an Android target. Do not adopt it as a general root management solution, because it is a mount mechanism rather than a root framework, and it does not replace KernelSU or APatch. Before you build it, note that it needs a Rust nightly toolchain, the Android NDK, cargo-ndk and Node.js with pnpm, and that the author says updates will slow down for academic reasons.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Tools-cx-app/meta-magic_mount-rs on GitHub