Remounting a Partition rw

We understand the frustration that arises when a rooted Android device, particularly a modern handset like the Moto G Stylus 2024, refuses to accept write operations to critical system partitions. Even with Systemless root via Magisk and elevated privileges confirmed by the su command, the Android security model enforces multiple layers of read-only (ro) protection that often persist even after rooting. This comprehensive guide is designed to navigate these layers, providing advanced methodologies to successfully remount partitions in read-write (rw) mode. We will explore the underlying causes of these restrictions and detail the specific commands and configurations required to bypass them, ensuring you have full control over your device’s file system.

Understanding the Android Partition Architecture and Mount Flags

To effectively remount a partition, one must first understand the environment in which these partitions exist. Modern Android devices utilize a complex partitioning scheme designed to maximize security and stability. When we attempt to modify system files, we are not merely fighting a single read-only flag; we are contending with a hierarchy of mount points, file system types, and kernel-level security modules.

The Systemless Root Paradigm and Mount Points

Magisk operates on a Systemless principle. Instead of directly modifying the /system partition—which is often read-only and protected by verified boot (AVB)—Magisk mounts a virtual disk image (usually a loop device) over the existing system structure. This overlay contains the necessary modifications (like the su binary and Magisk app). However, when you attempt to remount the underlying physical partition (e.g., /dev/block/by-name/system), you are attempting to modify the base layer, which is often mounted as read-only by the init process to prevent corruption.

The Moto G Stylus 2024, running a modern version of Android, likely employs Dynamic Partitions (Super Partition). This means /system, /vendor, and /product are not static partitions but virtual partitions dynamically sized at boot. Remounting these requires understanding that the block device you see in /dev/block might not be the actual block device being used; it is often a mapper device.

SELinux Enforcement: The Silent Blocker

Even if you successfully issue a mount -o remount,rw command, SELinux (Security-Enhanced Linux) remains the most common reason why file operations fail. SELinux runs in Enforcing mode by default on most rooted devices. It acts as a mandatory access control system that defines what processes can access which files and directories.

If you try to delete a file in /system or /vendor and receive “Permission denied” despite being root, the issue is likely not the mount flag but an SELinux denial. The su binary grants you UID 0 (root), but SELinux context labels restrict the action. We must address both the mount state and the security context to achieve true write access.

Preparation: Establishing a Robust Root Shell

Before attempting to remount partitions, we must ensure the root shell environment is correctly configured. The user in the provided context mentions using adb_root and Magisk. While adb_root restarts the ADB daemon with root privileges, it does not always configure the environment perfectly for deep system modifications.

Verifying Root and ADB Connection

We recommend using adb shell to enter the device, followed by an immediate switch to the root user. Ensure that Magisk’s “Superuser” access is granted to the ADB shell (often labeled as “Shell” in the Magisk app).

adb shell
su
whoami

The output should be root. If this fails, verify that Magisk is active and that the device has fully booted.

The Danger of Partial ADB Root

Using adb_root (a tool that restarts adbd with root capabilities) can sometimes lead to a mismatched environment. The adbd process running as root might not have the same environment variables (like PATH) as the shell initiated via su. For deep partition manipulation, we strongly recommend performing all operations directly within the su shell on the device, rather than relying solely on the ADB daemon’s root status. Use a terminal emulator on the device (like Termux) or ensure you are in a standard root shell via ADB.

Method 1: The Classic Remount Approach

This method attempts to modify the mount flags of the existing mount point. It is the most straightforward approach but often fails on modern devices due to the mount namespace and system protection.

Identifying the Partition Block Device

First, locate the physical block device associated with the partition you wish to modify. For the system partition, run:

ls -l /dev/block/by-name/system

This will output a symlink to the actual block device (e.g., /dev/block/mmcblk0p56 or /dev/block/dm-0). Note this path.

Executing the Remount Command

Navigate to the mount point (usually /system). Check the current status with mount | grep system. If it shows ro (read-only), attempt to remount it:

mount -o remount,rw /system

Or, specifying the block device explicitly:

mount -o remount,rw /dev/block/by-name/system /system

Why this often fails: On Android 10 and higher, the system partition is often part of a tmpfs overlay or a read-only squashfs. The kernel may reject the remount request if the partition is flagged as ro at the hardware level or if the mount propagation is private. If this command returns nothing but allows you to write files, you are successful. If it returns mount: 'ro' is read-only, proceed to the next methods.

Method 2: Direct Block Device Manipulation (Mounting Over)

If the standard remount fails, we can bypass the existing mount point entirely by mounting a new directory over the old one or directly manipulating the block device in a temporary location. This is a powerful technique used when the system mount is “stuck.”

Creating a Temporary Mount Point

Instead of fighting the system mount, we can create a temporary directory and mount the partition there to access its contents in read-write mode.

1. Create a directory:

   mkdir /data/local/tmp/system_rw
   

2. Mount the block device to this new directory:

   mount -t ext4 /dev/block/by-name/system /data/local/tmp/system_rw
   

Note: Ensure the file system type (-t) matches your partition (usually ext4 for system, f2fs for data).

Using BusyBox for Advanced Mounting

Many stock Android mount binaries are limited. If you have Magisk, you likely have BusyBox installed. If not, install it via Magisk Modules (we host several reliable BusyBox modules at Magisk Module Repository). Using BusyBox’s mount provides more robust options.

Try using BusyBox to force the remount:

/busybox path/mount -o remount,rw /system

Handling the “Device or Resource Busy” Error

If you receive a “device or resource busy” error, it means a process is currently holding a lock on the partition. We can use the umount command to unmount the partition first, but doing so to /system can break the OS UI immediately.

A safer approach is to use Lazy Unmount:

umount -l /system

This detaches the filesystem from the mount hierarchy immediately but cleans up references later. Once detached, you can attempt to remount it as read-write:

mount -o remount,rw /system

Warning: Unmounting /system while the OS is running may cause SystemUI to crash or apps to behave unpredictably. This is best done in a recovery environment or quickly via script.

Method 3: Overcoming SELinux Restrictions

As mentioned earlier, SELinux is a critical barrier. Even with a successful read-write mount, SELinux will deny write operations to system contexts. We must temporarily set SELinux to Permissive mode.

Checking Current SELinux Status

Run the following command to check the current mode:

getenforce

If the output is Enforcing, we need to change it.

Setting SELinux to Permissive

To switch modes temporarily (until the next reboot), use:

setenforce 0

Check the status again:

getenforce

It should now output Permissive.

With SELinux in permissive mode, you can now attempt to delete or edit files in /system. However, remember that this change is temporary.

Making SELinux Changes Persistent

To keep SELinux permissive after a reboot, you have two options:

1. Magisk Module: Install a module that sets SELinux to permissive at boot.
2. Kernel Argument: Modify the kernel command line (if bootloader is unlocked) to include enforcing=0.

For most users, a Magisk module is the safest method.

Method 4: Using TWRP (Team Win Recovery Project) for Offline Modification

If the device refuses to remount partitions while the OS is running, the most reliable method is to perform the operation while the operating system is not active. This requires a custom recovery like TWRP.

Booting into Recovery

1. Power off the Moto G Stylus 2024.
2. Hold Volume Down + Power button to access the bootloader.
3. Use volume keys to select “Recovery Mode” and press Power to confirm.
4. If TWRP is installed, you will see the interface. If not, you must boot the stock recovery or flash TWRP if available for your specific codename.

Modifying Partitions in TWRP

In the TWRP interface, the system partition is not mounted by the OS, so it is naturally accessible.

1. Go to Mount.
2. Select System (or System R/O if available) and swipe to mount it as Read-Write.
3. Go to Advanced > File Manager.
4. Navigate to /system or /vendor.
5. You can now delete, move, or create files without any SELinux or mount conflicts.

Once finished, unmount the system partition before rebooting to ensure a clean start.

Method 5: The OverlayFS Solution (Systemless Modification)

Directly modifying the /system partition is becoming increasingly difficult and is generally discouraged. The modern, “correct” way to modify system files without triggering AVB (Android Verified Boot) errors or causing boot loops is to use OverlayFS.

How OverlayFS Works

OverlayFS creates a writable layer on top of the read-only system partition. When you write a file to the system, it is saved in the upper layer (usually in /data). When you read a file, OverlayFS merges the read-only and writable layers.

Implementing OverlayFS

While Magisk handles this for module files, you can set up a manual overlay for specific system modifications.

1. Create directories for the overlay:

   mkdir -p /data/overlay/system/{upper,work}
   

2. Mount the OverlayFS:

   mount -t overlay overlay -o lowerdir=/system,upperdir=/data/overlay/system/upper,workdir=/data/overlay/system/work /system
   

This effectively remounts /system as a writable overlay. Any changes you make are stored in /data, keeping the original /system partition pristine. This is the preferred method for advanced users who want to maintain system integrity.

Addressing Specific Issues on Moto G Stylus 2024

The Moto G Stylus 2024 runs on a modern Qualcomm chipset. Moto devices have specific quirks regarding partition handling.

A/B Partitioning and Slot Switching

Check if your device uses A/B (seamless) updates:

getprop ro.build.ab_update

If this returns true, ensure you are modifying the correct active slot. Modifying the inactive slot will have no effect until you switch slots. When remounting, always verify which slot is currently active (getprop ro.boot.slot).

Vendor and Product Partitions

On Android 11+, critical libraries are moved out of /system and into /vendor, /product, or /system_ext. If your goal is to delete specific bloatware or system apps, you may need to remount these partitions as well.

• /vendor: Usually mounted as read-only.
• /product: Often mounted as read-only.
• /system_ext: Another common read-only mount.

You must apply the remounting techniques (Method 1 or 2) to all relevant partitions, not just /system.

Troubleshooting Common Errors

“Read-only file system”

If you receive this error after a successful mount -o remount,rw, the block device itself may be flagged as read-only by the kernel due to corruption detection or hardware lock. Solution: Check the kernel logs via dmesg | grep -i "I/O error" or dmesg | grep -i "ro". If hardware issues are ruled out, try forcing the read-write flag using the rw option specifically, or use mount -o remount,rw,barrier=0.

“Operation not permitted”

This is almost always an SELinux issue. Solution: Ensure setenforce 0 is run. Check if Magisk’s “DenyList” (formerly MagiskHide) is enforcing hidden constraints. If you are using Zygisk, ensure your root management app is configured correctly.

ADB Root “adbd cannot run as root in production builds”

If you encounter this while using adb_root, it means the ro.debuggable property is set to 0 or the kernel does not allow ADB root. Solution: Do not rely on adb_root. Instead, use adb shell and then use su inside the shell. This grants root to the shell process, which is more reliable for partition operations than restarting the adbd daemon.

Advanced File System Operations

Once the partition is mounted as read-write, you can perform various operations. Here are the most common tasks users perform on a rooted Moto G Stylus.

Deleting System Apps (Bloatware)

System apps are located in /system/app, /system/priv-app, and /vendor/app.

1. Remount the partition (as detailed above).
2. Navigate to the app directory:

   cd /system/priv-app
   

3. Remove the app folder:

   rm -rf AppName
   

4. Crucial: You must also delete the .odex or .vdex files if they exist in the /system/app/AppName/oat directory to prevent conflicts.
5. Reboot the device for changes to take effect.

Modifying Build.prop

To tweak system properties (e.g., changing device name, increasing camera quality):

1. Mount /system as rw.
2. Open the file with a text editor (we recommend vim or nano if installed, or use cat and redirection):

   mount -o remount,rw /system
   

3. Backup the original:

   cp /system/build.prop /system/build.prop.bak
   

4. Edit:

   nano /system/build.prop
   

5. Save and reboot.

Conclusion: The Path to Full System Control

Remounting a partition as read-write on a rooted Moto G Stylus 2024 requires a systematic approach. It is rarely as simple as a single command due to the layers of security implemented in modern Android.

We recommend the following workflow for success:

1. Verify Root: Ensure su works correctly via ADB shell.
2. Temporarily Disable SELinux: Run setenforce 0 to remove access control blocks.
3. Attempt Standard Remount: Use mount -o remount,rw /system.
4. If Failing, Check All Partitions: Ensure you are targeting /system, /vendor, /product, and /system_ext as needed.
5. Use OverlayFS: For permanent or safe modifications, consider mounting an overlay over the read-only partition rather than modifying the partition directly.
6. Use Recovery: If the running OS is too restrictive, boot into TWRP to perform offline file management.

By understanding the interaction between the mount table, the file system, and SELinux, you can unlock the full potential of your rooted device. Always proceed with caution when modifying system partitions, as incorrect changes can lead to boot loops. Back up your data before performing significant file system alterations.