Database Develop

How To Guide How to change the home directory for the user root on an Android phone

How to change the home directory for the user root on an Android phone
When working a lot in a shell via adb on an Android phone it's usefull to be able to store some user dependent config files in the home directory of the user. So let's see how that can be implemented on a phone running Android.
Note: The config was done and tested on a phone running OmniROM (based on Android 12)
The home directory for all user used in an (adb) shell on Android is the root directory "/".
Using a home directory for more then one user is not really usefull and in addition on Android "/" is mounted read-only so more or less useless as home directory.
Therefor this should be changed . Unfortunately there is no /etc/passwd file in Android to configure the home directory for a user.
Well, there is an /etc/passwd file (probably for compatibily reasons) but it's empty:
Code:
[email protected]_I006D:/ $ ls -l /etc/passwd
-rw-r--r-- 1 root root 0 2009-01-01 01:00 /etc/passwd
[email protected]_I006D:/ $
And as far as I know there is no other config file to configure the home directory of the user in the Android OS.
So we must implement some work around to get this working.
The shell on Android behaves like normal shells on Linux and executes the file /etc/profile when starting a new session.
In Android /etc is a symbolic link to /system/etc:
Code:
[email protected]_I006D:/ # ls -ld /etc
lrw-r--r-- 1 root root 11 2009-01-01 01:00 /etc -> /system/etc
[email protected]_I006D:/ #
And in the default config there is no file called profile in that directory:
Code:
[email protected]_I006D:/ $ ls -l /etc/system/profile
ls: /etc/system/profile: No such file or directory
[email protected]_I006D:/ $
Because /system is also mounted read-only we need the magic tool Magisk again to create the file /system/etc/profile.
To create the file /system/etc/profile create these directories and files on the phone as user root (assuming Magisk is already installed on the phone):
Code:
[email protected]_I006D:/ # find /data/adb/modules/initshell/
/data/adb/modules/initshell/
/data/adb/modules/initshell/system
/data/adb/modules/initshell/system/etc
/data/adb/modules/initshell/system/etc/profile
[email protected]_I006D:/ #
and reboot the phone. After the reboot there should be the writable file /etc/profile:
Code:
[email protected]_I006D:/ # ls -l /etc/profile
-rw-rw-rw- 1 root root 1100 2022-07-14 14:51 /etc/profile
[email protected]_I006D:/ #
which is in reality the file
Code:
/data/adb/modules/initshell/system/etc/profile
Now you can edit the file /etc/profile as user root until it fullfills your requirements (be aware that all changes in that file are now persistent).
To test the changes open a new adb session (you should not close the current adb session to be able to fix an error in the profile if opening a new adb session fails).
This file can now be used to define the home directory for the user. The home directory should be on one of the writable filesystem, e.g. in /data:
Code:
# add in /etc/profile
HOME="/data/home/root"
export HOME
and the result is:
Code:
[email protected]_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:su:s0
[email protected]_I006D:/ # echo $HOME
/data/home/root
[email protected]_I006D:/ #
Note that there is not really a writable filesystem for the user shell so this approach to change the home directory is mainly usable for the user root.
The file /etc/profile can also be used to init some other settings for (adb) sessions (e..g. change the PATH, etc) . This feature can be used for sessions for non-root users also.
For additional user dependent configs you can also create the file .profile in the home directory of the user; the file ${HOME}/.profile will be executed after the execution of the file /etc/profile.
Notes:
Be aware that creating a profile for the user root and changing the home directory for the user root might have some side effects on other processes using the shell!
Therefor it's recommended to use the command "tty -s" to test if the profile is executed in an interactive session:
Code:
#
# check if we're running in an interactive session
#
if ! tty -s; then
#
# this is not an interactive session - so we're just doing nothing at all
#
:
else
#
# running in an interactive session
#
...
fi
You can also check if the parent process is the adb daemon to not do anything in non-adb sessions.
Code:
ps -fp $PPID| grep adbd >/dev/null
if [ $? -ne 0 ] ; then
#
# not running in an adb session
:
else
#
# running in an adb session
...
fi
For testing purpose I suggest to open at least two shells via adb to be able to fix an error in case opening a new shell fails due to a bug in the profile.
If opening a shell session fails due to an error in the /etc/profile and you do not have another open shell either delete the file /data/adb/modules/initshell/system/etc/profile with a filemanager with root access on the phone or boot the phone from a recovery image (like TWRP) and delete or edit the file /data/adb/modules/initshell/system/etc/profile.
I initially looked at this feature to enable a persistent command history for the shell on the Android phone. But after some google searches I found out that persistent history shells are disabled for the shell binary on Android. So this will not work without recompiling the shell binary.
The attached example for the profile (rename the attached file profile.txt to profile) will use the directory /data/home/root as home directory for the user root and will not change the home directory for other users. The profile will do nothing if not running in an interactive session.
The directory /data/home/root will be created by the profile if it does not yet exist.
As always, if the config is working you should create a real Magisk Module for the profile.
The Magisk Module attached, initshell.zip, can be used to create a Magisk Module with your own profile:
To create a new Magisk Module with your own /etc/profile do:
Code:
# create an empty working directory
#
TEMPDIR="/tmp/newdir"
mkdir "${TEMPDIR}"
cd "${TEMPDIR}"
# unpack the zip file in the new directory
#
unzip ../initshell.zip
# now edit the file ${TEMPDIR}/system/etc/profile
# also (optional) edit the files config.sh and module.prop in the new directory to document your changes
# the script customize.sh from the module will be executed once when the module is installed. You might add the code
# create the home directories or any other code here
#
# and recreate the zip file
#
zip -r ../initshell.zip .
Note:
Both attached files are also available from my web site: http://bnsmb.de/My_HowTos_for_Android.html

How To Guide How to run a script at shutdown

How to run a script at shutdown
To define additional startup scripts via Magisk the Magisk directories /data/adb/service.d and /data/adb/post-fs-data.d can be used. Unfortunately there is no equivalent for scripts that should be executed during shutdown.
So we must use other methods to implement these kind of scripts.
Using the overlay feature of Magisk to run a script at shutdown
Introduction
in Android it is possible to define actions that will be executed when certain conditions are satisfied.
These definitions are done in the file init.rc (and other .rc files) using the Android Init Language.
And this feature can be used to execute a command when the phone is shutting down.
Note:
For details about the Android Init Language used for these files see here https://android.googlesource.com/platform/system/core/+/master/init/README.md
The .rc files used by Android are in the directories
/system/etc/init​/vendor/etc/init​/odm/etc/init​
Note: The first .rc file read is /system/etc/init/hw/init.rc
Unfortunately it's useless to change the .rc files in these directories using the Magisk features to change files in the directory /system because these files are processed by the OS before the new files are "created" by Magisk.
Therefor the overlay functionality from Magisk must be used to create additional .rc files (see the section Root Directory Overlay System on this page https://github.com/topjohnwu/Magisk/blob/master/docs/guides.md for details about this Magisk Feature).
Preparation
To be able to restore the original boot partition in case of an error create an image of the original boot partition from the phone on your PC before starting the development:
Code:
CUR_SLOT=$( adb shell getprop ro.boot.slot_suffix )
adb shell su - -c dd if=/dev/block/by-name/boot${CUR_SLOT} | cat >boot${CUR_SLOT}
e.g.
Code:
[ OmniRomDev - [email protected] /data/develop/android/test ] $ CUR_SLOT=$( adb shell getprop ro.boot.slot_suffix )
[ OmniRomDev - [email protected] /data/develop/android/test ] $ echo ${CUR_SLOT}
_b
[ OmniRomDev - [email protected] /data/develop/android/test ] $
[ OmniRomDev - [email protected] /data/develop/android/test ] $ adb shell su - -c dd if=/dev/block/by-name/boot${CUR_SLOT} | cat >boot${CUR_SLOT}.img
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 2.668147 s, 36 M/s
[ OmniRomDev - [email protected] /data/develop/android/test ]
[ OmniRomDev - [email protected] /data/develop/android/test ] $ ls -ltr boot${CUR_SLOT}.img
-rw-r--r--. 1 xtrnaw7 xtrnaw7 100663296 Oct 1 12:13 boot_b.img
[ OmniRomDev - [email protected] /data/develop/android/test ] $
To trouble shoot issues with this approach it is highly recommended to create an Magisk init script in the directory
/data/adb/post-fs-data.d
to fetch and store the Android logs into a persistent file. Use these commands to create the script:
Code:
cat >/data/adb/post-fs-data.d/0002logcatboot <<-EOT
mkdir -p /cache/logs
# backup the OS logs from before the reboot:
#
[ -r /cache/logs/log ] && mv /cache/logs/log /cache/logs/oldlog
/system/bin/logcat -r 102400 -n 9 -v threadTime -f /cache/logs/log >/cache/logs/info.log 2>/cache/logs/err.log &
EOT
chmod 755 /data/adb/post-fs-data.d/0001logcatboot
Using this script the log messages from before the last reboot are stored in the file /cache/logs/oldlog.
To activate the script the phone must be rebooted.
Check the contents of the directory /cache/logs/log after the reboot as user root to be sure that it works.
Code:
[email protected]_I006D:/ $ su - -c ls -ltr /cache/logs
total 205008
-rw-rw-rw- 1 root root 0 1970-01-06 08:16 info.log
-rw-rw-rw- 1 root root 0 1970-01-06 08:16 err.log
-rw-r----- 1 root root 4707523 2022-10-01 17:29 log
[email protected]_I006D:/ $
Details
The trigger in the .rc files for the action that should be done while shutting down is
on shutdown
The trigger can be used more then once; the OS will execute all defined actions for the trigger in the order they are found in the rc files.
The action to run an executable in the .rc file is
exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]
Fork and execute command with the given arguments. The command starts after “--” so that an optional security context, user, and supplementary groups can be provided. No other commands will be run until this one finishes. seclabel can be a - to denote default. Properties are expanded within argument. Init halts executing commands until the forked process exits.
Click to expand...
Click to collapse
In Android SELinux is enabled by default. Therefor it's neccessary to use the correct SELinux context for the files used.
(Note: The SELinux context for the init process executing the action is u:r:init:0 )
It's quite difficult to find the correct SELinux contexts in Android for this approach therefor it's better to use the general SELinux context defined by Magisk: u:r:magisk:s0 .
Implementation
Note:
All commands must be done as user root in an session on the phone or in an adb session.
So first create the neccessary directories and files:
Code:
mkdir -p /data/init_scripts
mkdir -p /data/init_scripts/log
Create the script to execute on shutdown:
Code:
cat >/data/init_scripts/my_shutdown.sh <<-\EOT
#!/system/bin/sh
SHUTDOWN_LOG="/data/init_scripts/log/myshutdown.$$.log"
echo "$0: Shutdown with parameter \"$*\" started at $( date ) " >>${SHUTDOWN_LOG}
echo "*** id : " >>${SHUTDOWN_LOG} 2>&1
id >>${SHUTDOWN_LOG} 2>&1
# ... add necessary commands ...
EOT
chmod 755 /data/init_scripts/my_shutdown.sh
Correct the SELinux context:
Code:
chcon -R u:r:magisk:s0 /data/init_scripts/
Check the result
Code:
[email protected]_I006D:/ # find /data/init_scripts/ -exec ls -ld {} \;
drwxr-xr-x 3 root root u:r:magisk:s0 3452 2022-10-01 16:12 /data/init_scripts/
-rwxr-xr-x 1 root root u:r:magisk:s0 637 2022-10-01 16:12 /data/init_scripts/my_shutdown.sh
drwxr-xr-x 2 root root u:r:magisk:s0 3452 2022-10-01 16:16 /data/init_scripts/log
[email protected]_I006D:/ #
Create a working directory:
Code:
#
# create a working directory
#
mkdir -p /data/adb/workdir
cd /data/adb/workdir
Now create the additional .rc file:
Code:
#
# change the current directory to the working directory
#
cd /data/adb/workdir
cat >init.custom.rc <<-\EOT
on shutdown
exec u:r:magisk:s0 -- /system/bin/sh /data/init_scripts/my_shutdown.sh 0008
on early-init
setprop my_custom_rc_file loaded
EOT
Note:
The additional trigger for early-init is for testing the new .rc file (see the trouble shooting section below for details). Magisk supports more then one .rc file; the name of the .rc file is meaningless but the extension must be .rc.
And now add the new file to the ramdisk on the boot partition:
Code:
#
# change the current directory to the working directory
#
cd /data/adb/workdir
# get the current active slot
#
CURRENT_SLOT=$( getprop ro.boot.slot_suffix )
echo "The current active slot is: ${CURRENT_SLOT}"
# copy the boot partition from the active slot to a file
#
dd if=/dev/block/by-name/boot${CURRENT_SLOT} of=./boot_root.img
# unpack the image file
#
/data/adb/magisk/magiskboot unpack ./boot_root.img
# add the new dirs and files to the ramdisk from the boot partition
#
/data/adb/magisk/magiskboot cpio ramdisk.cpio \
"mkdir 0700 overlay.d" \
"add 0700 overlay.d/init.custom.rc init.custom.rc"
# recreate the image file for the boot partition
#
/data/adb/magisk/magiskboot repack boot_root.img
# write the corrected image file to the boot partition
#
dd if=./new-boot.img of=/dev/block/by-name/boot${CURRENT_SLOT}
Note:
The commands to unpack and pack the ramdisk manually using the cpio command are (if NOT using the Magisk binary magiskboot):
Code:
RAMDISK=$PWD/ramdisk
mkdir ${RAMDISK}
cd ${RAMDISK}
# unpack the ramdisk
#
cpio -idm <../ramdisk.cpio
# ... do what ever is necessary with the files/dirs in ${RAMDISK}
# pack the ramdisk again
#
cd ${RAMDISK}
find . | cpio -o >../ramdisk.cpio
Now reboot the phone to activate the new .rc config and after the reboot check that the .rc file was processed
Code:
getprop my_custom_rc_file
e.g
Code:
[email protected]_I006D:/ $ getprop my_custom_rc_file
loaded
[email protected]_I006D:/ $
If the property defined in the .rc file, my_custom_rc_file, is not set something went wrong and you should check the OS logs and double check your config.
If the new property is defined you can test the shutdown action by rebooting the phone again.
While doing this reboot the new shutdown script should be executed and after the reboot is done there should be the log file from the shutdown script:
Code:
[email protected]_I006D:/ $ su -
[email protected]_I006D:/ # ls -l /data/init_scripts/log
total 0
-rw------- 1 root root 179 2022-10-01 18:23 myshutdown.4617.log
[email protected]_I006D:/ # cat /data/init_scripts/log/myshutdown.4617.log
/data/init_scripts/my_shutdown.sh: Shutdown with parameter "0008" started at Sat Oct 1 18:23:14 CEST 2022
*** id :
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
[email protected]_I006D:/ #
That's it.
Note that you can change the script executed while doing the shutdown without changing the boot image again.
But you should always test the script before rebooting -- an error in your script may stop the reboot.
To change the additional .rc files it's necessary to recreate the ramdisk and boot partition.
The filesystems for /data and for /sdcard are still mounted while executing the actions for the trigger "on shutdown" .
To log the current environment while executing the shutdown script you can add code like this to the script:
Code:
(
echo
echo "*** Environment while executing the shutdown script ..."
echo
echo "*** pwd: "
pwd
echo
echo "*** id: "
id
echo
echo "*** df -h: "
df -h
echo
echo "*** ps -efZ : "
ps -efZ
echo
echo "*** env: "
env
echo
echo "*** set: "
set
echo
) >>/data/init_scripts/log/myshutdown_env.log 2>&1
To create a directory in which other actions from the .rc file (like write) can write with SELinux enabled use one of the SELInux contexts the init process can write to, e.g:
Code:
mkdir /data/system_data
chcon u:object_r:system_data_file:s0 /data/system_data
Now the .rc config
Code:
on shutdown
write /data/system_data/myshutdown.log Shutdown_started\n
will work.
See the file ./plat_file_contexts in the ramdisk from the boot partition for other existing SELinux contexts, e.g.:
Code:
[email protected]_I006D:/data/adb/test # /data/adb/magisk/magiskboot cpio ramdisk.cpio "extract plat_file_contexts plat_file_contexts" <
Loading cpio: [ramdisk.cpio]
Extract [plat_file_contexts] to [plat_file_contexts]
[email protected]_I006D:/data/adb/test # ls -l plat_file_contexts
-rw-r--r-- 1 root root 40490 2022-10-03 16:27 plat_file_contexts
[email protected]_I006D:/data/adb/test #
Please be aware that these changes will be gone after the next OS update. But on the other hand it's quite easy to create a script to re-install the shutdown script without user intervention.
Trouble Shooting
The main reason for problems with this approach are invalid SELinux contexts. Therefor you should test your script in permissive SELinux mode if it does not work like expected. To do that temporary disable SELinux before rebooting (SELinux will be automatically enabled again after the reboot), e.g.:
Code:
# set SELinux to permissive
#
setenforce 0
reboot
and check the log messages in the directory /cache/logs/oldlog for SELinux related messages:
Code:
su - -c grep deny /cache/logs/oldlog
Note that you can not disable SELinux in an action in an .rc file.
To check if your additional .rc file is processed by Magisk add a statement like these to the custom .rc file in the overlay directory:
Code:
on early-init
setprop sys.example.foo bar
If this statement is processed by Magisk and Android the property sys.example.foo should be defined after the reboot, e.g.:
Code:
[email protected]_I006D:/ # getprop sys.example.foo
bar
[email protected]_I006D:/ #
To check if the "on shutdown" trigger is processed use :
Code:
on shutdown
write /sdcard/Download/myshutdown.log Shutdown_started\n
and reboot with disabled SELinux:
Code:
setenforce 0
reboot
If the "on shutdown" trigger in your .rc file is processed there should exist the file
/sdcard/Download/myshutdown.log
after the reboot
If the shutdown of the phone hangs open another adb session to the phone and kill the script (the adb daemon should still run while the shutdown script is running).
If the phone does not boot anymore with the new shutdown script reboot the phone from the TWRP image and fix / delete the new shutdown script. Or reflash the boot partition with the image file created before starting the development.
In general you should carefully check your .rc file for syntax errors -- entries in the file after the first syntax error will be ignored
Useful URLs
I used ideas and code from the web pages listed below for this HowTo:
How to run an executable on boot and keep it running?
How to run an Android init service with superuser SELinux context?
Magisk overlay - execute a script or copy files
History
03.10.2022 /bs
added code about to extract a single file (plat_file_contexts) from the ramdisk cpio image using magiskboot

How To Guide How to make files in /system writable

How to make files in /system writable
In Android 12 and newer /system is mounted read-only can not be remounted read-write anymore.
Sometimes it's useful that one or more files in /system are writable (for example for develop tasks or for testing)
This can be implemented using Magisk (see How to change files in the directory /system for more details)
Example :
Make the file /system/etc/vimrc writable
Note:
In Android 12 /etc is a symbolic link to /system/etc.
Open a (adb) shell as user root and do
Bash:
# create a dummy Magisk module
#
mkdir -p /data/adb/modules/writable_system/system/etc
# copy the file that should be writable to the Magisk module directory
#
cp /system/etc/vimrc /data/adb/modules/writable_system/system/etc/
# make the file in the Magisk module directory writable
#
chmod +w /data/adb/modules/writable_system/system/etc/vimrc
Now reboot the phone.
After the reboot the file /system/etc/vimrc is writable by the user root, Example:
Code:
ASUS_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
ASUS_I006D:/ #
ASUS_I006D:/ # ls -l /system/etc/vimrc
-rw-r--r-- 0 root root 3350 2022-11-04 11:36 /system/etc/vimrc
ASUS_I006D:/ # tail -2 /system/etc/vimrc
\ | wincmd p | diffthis
endif
ASUS_I006D:/ #
ASUS_I006D:/ # echo '" Test Comment' >>/system/etc/vimrc
ASUS_I006D:/ #
ASUS_I006D:/ # tail -2 /system/etc/vimrc
endif
" Test Comment
ASUS_I006D:/ #
Only the user root can access the directory /data/adb. Therefor the files configured using this approach are only writable by the user root.
To make a file in /system writable for non-root users use this method:
Open a (adb) shell and execute as user shell:
Bash:
#
# create a directory that is writable for the user shell
#
mkdir /data/local/tmp/writable_system
mkdir /data/local/tmp/writable_system/etc
#
# copy the file that should be writable to that directory
#
cp /system/etc/vimrc /data/local/tmp/writable_system/etc
The next commands must be executed as user root:
Bash:
# create dummy Magisk module
#
mkdir -p /data/adb/modules/writable_system/system/etc
#
# create a symbolic link to the file in the writable directory in the directory with the dummy Magisk module
#
ln -s /data/local/tmp/writable_system/etc/vimrc /data/adb/modules/writable_system/system/etc
Now reboot the phone.
After the reboot the file /system/etc/vimrc is writable by the user shell, Example:
Code:
ASUS_I006D:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:shell:s0
ASUS_I006D:/ $
ASUS_I006D:/ $ tail -2 /system/etc/vimrc
\ | wincmd p | diffthis
endif
ASUS_I006D:/ $
ASUS_I006D:/ $ echo '" Test Comment' >>/system/etc/vimrc
ASUS_I006D:/ $
ASUS_I006D:/ $ tail -2 /system/etc/vimrc
endif
" Test Comment
ASUS_I006D:/ $
Important:
The writable directory can also be in a sub directory in /sdcard. But be aware that /sdcard is mounted late in the boot process so it might be that the overwritten file in /system will be used by the OS when the bind mount points to a non-existent file if using a sub directory in /sdcard.
The changes to the file done using these methods are "persistent" as long as Magisk is installed in the boot partition.
To restore the file with the original contents after each new reboot of the phone without removing the writable config open a (adb) shell as user root and execute:
Bash:
#
# restore the file /data/adb/modules/writable_system/system/etc/vimrc from the original file /system/etc/vimrc
#
# this must be done before Magisk creates the bind mounts
#
echo "cp /system/etc/vimrc /data/adb/modules/writable_system/system/etc/vimrc">/data/adb/post-fs-data.d/restore_vimrc.sh
chmod 755 /data/adb/post-fs-data.d/restore_vimrc.sh
Now the file in the dummy Magisk module will be restored with the contents of the original file from /system after each reboot
To temporary access the original file from /system just stop the Magisk daemon, Example:
Code:
ASUS_I006D:/ # echo '"Test Test' >>/etc/vimrc
ASUS_I006D:/ #
ASUS_I006D:/ # tail -1 /etc/vimrc
"Test Test
ASUS_I006D:/ #
ASUS_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
ASUS_I006D:/ #
ASUS_I006D:/ # magisk --stop
ASUS_I006D:/ #
ASUS_I006D:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
ASUS_I006D:/ #
ASUS_I006D:/ # tail -1 /etc/vimrc
endif
ASUS_I006D:/ #
Note
Stopping the Magisk daemon will disable all bind mounts done by Magisk.
Restarting the Magisk daemon will not re-create the bind mount - to re-activate the bind mount for the writable file after stopping the Magisk daemon the phone must be rebooted.
To make more then one file writable in a sub directory in /system you can also replace the complete folder using these commands as user root:
Bash:
#
# make all files in /system/etc writable by the user root
#
mkdir -p /data/adb/modules/writable_system/system/etc/
cd /system/etc
find . | cpio -pdum /data/adb/modules/writable_system/system/etc/
touch /data/adb/modules/writable_system/system/etc/.replace
Now Magisk will replace the directory /system/etc with the directory /data/adb/modules/writable_system/system/etc after the next reboot
Notes
You should test these commands with a not important file like /system/etc/vimrc before changing important files.
It is NOT recommended to use this approach on productive phones.
See How to change any file or directory using Magisk for another approach to change files on read-only mounted filesystems.
Trouble Shooting
As always: If something does not work like expected check the Magisk log file /cache/magisk.log and also check the infos in this post.

Does this method require root on device?

FormulaSea said:
Does this method require root on device?
Click to expand...
Click to collapse
yes

Is there any method don't require root?

This looks interesting. Are you using OverlayFS for this? Looks like you did quite the research on this
Read-only is boring even as root. It's time for some RW baby

FormulaSea said:
Does this method require root on device?
Click to expand...
Click to collapse
I don't know a method to do this without root access.
But you can disable the root access in Magisk after implementing the changes . You could even uninstall tne Magisk app afterwards (but not the Magisk part from the boot partition)
regards
Bernd

lebigmac said:
This looks interesting. Are you using OverlayFS for this? Looks like you did quite the research on this
Read-only is boring even as root. It's time for some RW baby
Click to expand...
Click to collapse
I don't know what exactly you mean by "OverlayFS" - I use MagiskModules to modify files in /system and as far as I know Magisk used bind mounts to implement it.
>>Read-only is boring even as root.
Correct, but if you made the changes directly in /system, they would not survive the next OS upgrade.
One of the great advantages of this feature of Magisk is that it survives an OS upgrade - so as long as the change is compatible with the installed OS version, it only needs to be done once.
regards
Bernd

Thanks it worked on the audio folders on my 7t pro but didn't work on the boot animation folder. Both folders appear in the adb though with there files. Let me know op if you figure out how to do the boot animation folder it's moved to /my_product/ instead of /system/ I see that the my product folder and boot animation appear in the adb modules like the audio folder does and I swapped files the same way as with my audio modding but the changes for boot didn't take effect.

cbomb1337 said:
Thanks it worked on the audio folders on my 7t pro but didn't work on the boot animation folder. Both folders appear in the adb though with there files. Let me know op if you figure out how to do the boot animation folder it's moved to /my_product/ instead of /system/ I see that the my product folder and boot animation appear in the adb modules like the audio folder does and I swapped files the same way as with my audio modding but the changes for boot didn't take effect.
Click to expand...
Click to collapse
/my_product is not in the list of folders supported by Magisk so that may not work
Please post the output of these commands (executed as root user):
df -h
mount
ls -ald /*
ls -lZd /my_product
and a
ls -ldZ $( find /data/adb/modules/ )
and
cat /cache/magisk.log
(or attach the log file to the post if too big)
regards
Bernd

Here is this the correct log file. Thank you for responding to me.

cbomb1337 said:
Here is this the correct log file. Thank you for responding to me.
Click to expand...
Click to collapse
can you also post the output of the OS commands listed?

I Don't know how.

It didn't let me add the log here. Sorry that's it's cut and paste I tried a few termux commands to save a log but the were blank. I don't understand how to do it right.
Edit here I managed to upload the log to drive
https://drive.google.com/uc?id=1uWurf_462b5uLC_D21SFcgLcBWiXQZOn&export=download

bnsmb said:
can you also post the output of the OS commands listed?
Click to expand...
Click to collapse
Linefeeds are missing in that file so it's very hard to interpret the file contents correct
Can you do in a adb shell on the phone:
Bash:
(
set -x
set -v
su -
echo
df -h
echo
mount
echo
ls -ald /*
echo
ls -lZd /my_product
echo
ls -ldZ $( find /data/adb/modules/ )
echo
) > /sdcard/Download/oscmds.log 2>&1
then
Bash:
gzip /sdcard/Download/oscmds.log
and post / upload the file
/sdcard/Download/oscmds.log.gz
regards
Bernd
and

Here is the gzip I wasn't sure what was going on after entering that first command the termux was frozen for a few minutes. Also With the folders in the module folder and them being a copy of the original folder is it ok to delete them as a whole folder to remove the rw and revert it of needed. I tried it and didn't see any issues doing it but wanted to know if it reverted it properly and does deleting the module folders make me lose anything original that was in it or is my stock stuff safe because it's through magisk.

cbomb1337 said:
Here is the gzip I wasn't sure what was going on after entering that first command the termux was frozen for a few minutes. Also With the folders in the module folder and them being a copy of the original folder is it ok to delete them as a whole folder to remove the rw and revert it of needed. I tried it and didn't see any issues doing it but wanted to know if it reverted it properly and does deleting the module folders make me lose anything original that was in it or is my stock stuff safe because it's through magisk.
Click to expand...
Click to collapse
Looks like /my_product is a directory in the root filesystem but on the other hand there is a mount point called /mnt/vendor/my_product so I'm not sure about that.
If /my_product is really only a separate directory in the root filesystem the only method to change it is to manipulate the ramdisk used for booting the phone (only if the phone is using a ramdisk, of course).
Can you check if there are other directories called my_product:
find / -type d -name my_product 2>/dev/null
And, if there are any, compare the files in that directory with the files in the directory /my_product?
regards
Bernd

The only folder that has the same boot animation files is the /dev/ ones and the mnt one like you said.
It's all good if it can't be done i just found a magisk module before which works for flashing my boot animation

cbomb1337 said:
The only folder that has the same boot animation files is the /dev/ ones and the mnt one like you said.
Click to expand...
Click to collapse
Then it can't be done using the standard Magisk feature for making r/o mounted filesystems read-write.
cbomb1337 said:
It's all good if it can't be done i just found a magisk module before which works for flashing my boot animation
Click to expand...
Click to collapse
OK, do you have the URL?
And you could just check the contents of the zip file with the Magisk Module on how it's implemented
regards
Bernd

bnsmb said:
Then it can't be done using the standard Magisk feature for making r/o mounted filesystems read-write.
OK, do you have the URL?
And you could just check the contents of the zip file with the Magisk Module on how it's implemented
regards
Bernd
Click to expand...
Click to collapse
I read the module it mentions binding. I don't understand none of it :/ I upload the module here and removed the boot animation to make it small.

cbomb1337 said:
I read the module it mentions binding. I don't understand none of it :/ I upload the module here and removed the boot animation to make it small.
Click to expand...
Click to collapse
Cool -- that's the solution I also found in the meantime (and successfully tested it on my Zenfone 8)
In principle the module does for the bootanimation file what Magisk does if you replace some directories or files in /system
I will write a general HowTo how that works today or in the next days
regards
Bernd

How To Guide How to enable access via adb on a new installed OS

For automatic installation and configuration of a phone running the Android OS the access via adb is required. "Unfortunately" the access via adb is disabled in most Android distributions (in reality it is of course good that the access via adb is disabled in the default setting! See also the notes regarding the LineageOS at the end of this post))
There are (at least) two ways to enable access via adb:
Manually via the GUI of Android on the phone or via the Android command settings executed by the user root in a shell ,e.g.:
Bash:
settings put global development_settings_enabled 1
settings put global adb_enabled 1
The latter can also be done in a script in an adb shell -- but of course we need a working adb connection ....
One way around this problem is to use Magisk:
In principle this could be done using an init script for Magisk:
Magisk allows to run scripts while booting the phone (see How to run a script at every boot using Magisk); this feature could be used to enable adb via script.
Unfortunately, this method no longer works in the latest Android versions (Androd 12 and Android 13; Android 11 not tested):
Android now uses encryption for most of the files in the subdirectories in /data and to initiate the encryption keys for the files in these directories, the phone must boot once from the installed OS.
To use a Magisk init script to enable the access via adb, we need to create files in the directories /data/adb and /data/misc/adb. If you create these files while booting into TWRP recovery without a configured Android operating system, these files will be created unencrypted, making it impossible to boot the installed Android operating system:
If the Android operating system finds unencrpyted files in these directories at the first reboot, it boots into the installed recovery with the famous error message "Cannot load Android system. Your data may be corrupt" (see How to fix the error "Cannot load Android system. Your data may be corrupt" for details)
Fortunately, the Android operating system does not encrypt files in the directory /data/recovery (and therefore continues booting if there are already files in that directory) and the part of Magisk in the boot partition does not need the Magisk files /data/adb.
So to enable the access via adb using Magisk, we can create a script in the directory /data/recovery and a new Init .rc file for the Android operating system to execute that script while the Android OS is booting - for details about how to do that see How to trigger an action when a property is changed.
The working method to enable adb via Magisk is as follows:
- Boot the phone from a recovery (like TWRP)
- Install the new OS image but do not reboot the phone (see How to install an OS image using the TWRP binary twrp for how to install the OS via the cli commands from TWRP)
- Install Magisk into the boot partition of the phone and delete all files in /data/adb afterwards (see How to install Magisk into the boot partition using a script for how to install Magisk via script)
- copy a script to the directory /data/recovery on the phone that will enable access via adb using the Android command settings and copy the public ssl keys for the access via adb to the directory /data/misc/adb on the phone
- install a new init .rc file via Magisk which executes the script in the direcory /data/recovery to enable the access via adb - this script will be executed while doing the 1st reboot of the new installed Android OS.
(see How to trigger an action when a property is changed for how to add a new init .rc file using Magisk)
- reboot the phone
I wrote two scripts to enable adb using this method:
enable_adb_using_magisk.sh
The script enable_adb_using_magisk.sh must run in an adb session in TWRP after the new OS was installed and after Magisk has been installed into the boot partition but before the first reboot of the new installed operating system.
The script enable_adb_using_magisk.sh
- creates the script /data/recover/enable_adb_via_service.sh on the phone to enable adb and install the public ssl key for access via adb
- creates a new init *rc file using Magisk that will run the script /data/recover/enable_adb_via_service.sh on the phone while doing the 1st reboot (after the file encryption for the files /data is initalized by the Android OS)
To use the script enable_adb_using_magisk.sh manually after installing the new OS and Magisk do while the phone is booted into TWRP:
Bash:
#
# copy the script enable_adb_using_magisk.sh to the directory /tmp on the phone
#
adb push enable_adb_using_magisk.sh /tmp/enable_adb_using_magisk.sh
# copy the public ssl key for access via adb to the directory /tmp on the phone
#
adb push $HOME/.android/adbkey.pub /tmp/adbkey.pub
# execute the script /tmp/enable_adb_using_magisk.sh on the phone
#
adb shell sh /tmp/enable_adb_using_magisk.sh
# reboot the phone into the new installed OS
#
adb reboot
Notes:
The script enable_adb_using_magisk.sh installs the init *rc file into the boot partition from the slot for the next reboot: In this scenario this is the slot with the new installed OS.
To specify the boot partition to use add the boot partition as parameter, e.g.
Bash:
adb shell sh /tmp/enable_adb_using_magisk.sh _a
The init *rc service used is:
Spoiler: init *rc service to enable adb
Code:
#
# additional RC service to enable the access via adb after the 1st boot into the new installed Android OS
#
service bnsmb_enable_adb /system/bin/sh /data/recovery/enable_adb_via_service.sh
user root
group root
seclabel u:r:magisk:s0
disabled
oneshot
on zygote-start
setprop sys.bnsmb_enable_adb_done 0
start bnsmb_enable_adb
#
# Note: the following entries are for testing only!
#
on zygote-start
write /data/recovery/semfile Here_I_am
setprop sys.bnsmb.test.okay 0
The script enable_adb_using_magisk.sh creates the files adb_keys and adb_temp_keys.xml in the directory /data/misc/adb if the public ssl key /tmp/adbkey.pub exists on the phone.
Note that the file /data/misc/adb/db_temp_keys.xml is an Android Binary XML fIle (see How to change files in Android XML Binary format for details about Android Binary XML files)
To avoid the manual steps listed above I wrote another script:
enable_access_via_adb.sh
The script enable_access_via_adb.sh does all the steps listed above; the usage for enable_access_via_adb.sh is
Code:
[ OmniRom 13 Dev - [email protected] /data/develop/android/scripts_on_linux ] $ ./enable_access_via_adb.sh -h
enable_access_via_adb.sh version - v1.0.0.0 - shell script to enable adb access via an init .rc file configured via Magisk
enable_access_via_adb.sh [-h|help|-H] [--reboot|--noreboot] [--nopubkey|--pubkey]
[ OmniRom 13 Dev - [email protected] /data/develop/android/scripts_on_linux ] $
Spoiler: Detailed Usage
Code:
[ OmniRom 13 Dev - [email protected] /data/develop/android/scripts_on_linux ] $ ./enable_access_via_adb.sh -H
enable_access_via_adb.sh version - v1.0.0.0 - shell script to enable adb access via an init .rc file configured via Magisk
Usage
enable_access_via_adb.sh [-h|help|-H] [--reboot|--noreboot] [--nopubkey|--pubkey]
All parameter are optional. The parameter can be used in any order.
Use the parameter "help" or "-H" to print the detailed usage help; use the parameter "-h" to print only the short usage help
If the parameter "--reboot" is used the script will reboot the phone after installing Init .rc file; to disable the automatic reboot use the parameter "--noreboot".
Default is to ask the user for confirmation to reboot the phone.
Use the parameter "--nopubkey" to disable configuring the public key of the current user on the PC for the access via adb; use the parameter "--pubkey" to configure
the public key; default is to configure the public key.
The default public ssl key used is the key in the file "${HOME}/.android/adbkey.pub".
To change some of the values used by the script these environment variables can be set before starting the script:
Set the environment variable PUBLIC_KEY_ON_PC to the file with the public ssl key to use for the access via adb if another public key should be used
Set the environment variable REBOOT to "yes" before starting the script to automatically reboot the phone after enabling the root access
Set the environment variable REBOOT to "no" before starting the script to disable the automatic reboot after enabling the root access
See also the source code of the script
boot_phone_from_twrp.sh
for environment variables supported by this script
Prerequisites
- the phone must be connected via USB
- Magisk must be already installed in the boot partition of the phone
- the phone must be either booted into the fastbootd or bootloader with a working fastboot connection
or already booted into a recovery image with working adb connnection
The scripts boot_phone_from_twrp.sh and enable_adb_using_magisk.sh are required by this script -- see the source code of the script
[ OmniRom 13 Dev - [email protected] /data/develop/android/scripts_on_linux ] $
So installing a new OS and enabling access via adb in a script without user intervention can be done using these commands:
Bash:
#
# do a factory reset and install the OS image using the TRWP binary twrp
#
REBOOT=no ./install_os_via_twrp.sh factory_reset /data/backup/ASUS_ZENFONE8/omnirom_local/omni-13/omni-13-20221211-zenfone8-MICROG.zip
# install Magisk into the boot sector of the partition with the new OS and delete all files in /data/adb afterwards
#
# The parameter delete_adb_dir for the script "install_magisk_via_twrp.sh" is only available in version 2.2.0.0 or newer of the script.
#
REBOOT=no ./install_magisk_via_twrp.sh next copy_apk delete_adb_dir
# enable adb and copy the public keys for adb via new init *rc file using Magisk in the boot partition
#
REBOOT=no ./enable_access_via_adb.sh
# reboot the phone
#
adb reboot
# wait until the new OS is booted and adb is enabled
#
adb wait-for-device
# install the Magisk App
#
./install_apk.sh /data/backup/Android/EssentialApps/Magisk-v25.2.apk
# install the Magisk directories and binaries in /data/adb
#
REBOOT=no ./install_magisk_via_twrp.sh adb_only
# (optional) enable root access for the adb shell
#
REBOOT=yes ./init_magisk_db.sh
Notes:
The script enable_access_via_adb.sh needs the helper script boot_phone_from_twrp.sh.sh and the script enable_adb_using_magisk.sh .
The scripts can be downloaded from my homepage:
enable_access_via_adb.sh
enable_adb_using_magisk.sh
boot_phone_from_twrp.sh
The other scripts mentioned in ths post can also be downloaded from my home page:
install_os_via_twrp.sh (see How to install an OS image using the TWRP binary twrp for a descripton of this script)
install_magisk_via_twrp.sh (see How to install Magisk into the boot partition using a script for a description for this script)
install_apk.sh (see How to install packages (apk files) for Android via script for a description for this script)
init_magisk_db.sh (see How to enable root access using Magisk in a script for a description for this script)
Disabling the service to enable access via adb
To only run once, the script enable_adb_using_magisk.sh creates the file /data/recovery/adb_initialized exists on the phone. If that file already exists when enable_adb_using_magisk.sh starts, the script will do nothing and end immediately.
Therefor, it's not necessary to delete the new init *rc service.
It might even be useful to leave the service installed, since it can be used for other purposes later by modifying the script
However, if necessary, you can either delete the script used by the init *rc service enable_adb_using_magisk.sh or reinstall the original boot partition to get rid of the new service completely:
Bash:
#
# while the phone is booted into the Android OS with enabled root access or while the phone is booted into TWRP
#
# use the parameter "yes" for the script to run without requesting user input
#
adb shell su - -c /data/recovery/work/restore_boot_partition.sh
Directories and files used
Name
Type
Content
Comment
/tmp/adbkey.pubfilessl public key that should be configured/tmp is on a ramdisk so this file is lost after booting the phone/data/recovery/workDirectorytemporary files used for enabling adb/data/recovery/work/enable_adb_via_service.rcfileinit *rc file added to the boot partition via Magiks/data/recovery/work/boot_a.imgfileimage of the original boot partition/data/recovery/work/original_boot_partition.imgSymLinklink to the image with the original boot partition/data/recovery/work/restore_boot_partition.shfileScript to restore the boot partition using the image of the original boot partition/data/recovery/work/header
/data/recovery/work/kernel
/data/recovery/work/ramdisk.cpiofilescontents of the boot partition/data/recovery/adbkey.pubfilepublic ssl key to be configured for access via adb/data/recovery/adb_temp_keys.xml.humanfileXML file with the configuration for the access via adb
(will be converted to an XML file in Android binary XML format in /data/misc/adb)/data/recovery/enable_adb_via_service.shfilescript to enable the access via adb and installl the public ssl key for the access via adb
The script is configured in the init*rc file /data/recovery/work/enable_adb_via_service.rc/data/recovery/enable_adb_via_service.logfilelog file created by the script /data/recovery/enable_adb_via_service.sh/data/recovery/adb_initializedfilesemphor file for the script /data/recovery/enable_adb_via_service.sh - if this file exists the script will do nothing/data/recovery/semfilefiletest file created by the new init *rc service/data/recovery/log.gz
/data/recovery/last_log.gz
/data/recovery/recovery.fstab
/data/recovery/storage.fstabfileFiles created by TWRPonly for information
Enabling access via adb in the LineageOS (Update 11.01.2023)
In the LineageOS 19 for the ASUS Zenfone 8 access via adb is enabled in the default configuration.
Therefor these instructions are not necessary. The only configuration that must be done on a phone running the LineageOS is to copy the public ssl keys to /data/misc/adb to enable the access via adb.
Unfortunately the method used for this described in this post seems not to work in the LineageOS.
In addition, root access via adb can be enabled in the developer settings in the LineageOS. Until now I did not find out how to enable the plain root access from the LineageOS from within a script.
userdebug builds
In userdebug builds of Android the access via adb (without authentification) is enabled in the default.
Trouble Shooting
The script enable_adb_using_magisk.sh uses the log file /data/recovery/enable_adb_via_service.log if executed via init *rc service.
To check if the init *rc file was configured successfully check the properties
sys.bnsmb_enable_adb_done
sys.bnsmb.test.okay
in the running Android OS. Both properties should be defined with the value 0:
Code:
ASUS_I006D:/ # getprop sys.bnsmb_enable_adb_done
0
ASUS_I006D:/ #
ASUS_I006D:/ # getprop sys.bnsmb.test.okay
0
ASUS_I006D:/ #
In addition, if everything worked there should exist the file /data/recovery/semfile.
Code:
130|ASUS_I006D:/ # ls -l /data/recovery/semfile
-rw------- 1 root root 9 2022-12-29 11:44 /data/recovery/semfile
ASUS_I006D:/ #
Use the Android command start to check if the service exists and can be started, e.g.
Spoiler: start bnsmb_enable_adb
Code:
ASUS_I006D:/ # start bnsmb_enable_adb ; dmesg | tail -10
[ 3069.861365] [ 3069.861365] (CPU:2-pid:1:init) [12:35:31.711593934] init: Service 'exec 613 (/system/bin/flags_health_check UPDATABLE_CRASHING)' (pid 5734) exited with status 0 waiting took 0.024000 seconds
[ 3069.861402] [ 3069.861402] (CPU:2-pid:1:init) [12:35:31.711630236] init: Sending signal 9 to service 'exec 613 (/system/bin/flags_health_check UPDATABLE_CRASHING)' (pid 5734) process group...
[ 3069.861618] [ 3069.861618] (CPU:2-pid:1:init) [12:35:31.711846069] libprocessgroup: Successfully killed process cgroup uid 1000 pid 5734 in 0ms
[ 3071.202534] [ 3071.202486] (CPU:2-pid:5077:wk:0xffffffe40) [12:35:33.052716433] [BAT][CHG]asus_jeita_cc_worker set BATTMAN_OEM_WORK_EVENT : WORK_JEITA_CC
[ 3071.220807] [ 3071.220807] (CPU:0-pid:350:wk:0xffffffe40) [12:35:33.071038100] [BAT][CHG]handle_message set property:16 successfully
[ 3071.570753] [ 3071.570753] (CPU:2-pid:1:init) [12:35:33.420982631] init: starting service 'bnsmb_enable_adb'...
[ 3071.575971] [ 3071.575971] (CPU:3-pid:1:init) [12:35:33.426199819] init: Control message: Processed ctl.start for 'bnsmb_enable_adb' from pid: 5735 (start bnsmb_enable_adb)
[ 3071.614570] [ 3071.614570] (CPU:3-pid:1:init) [12:35:33.464799298] init: Service 'bnsmb_enable_adb' (pid 5736) exited with status 0 oneshot service took 0.040000 seconds in background
[ 3071.614609] [ 3071.614609] (CPU:3-pid:1:init) [12:35:33.464837267] init: Sending signal 9 to service 'bnsmb_enable_adb' (pid 5736) process group...
[ 3071.614788] [ 3071.614788] (CPU:3-pid:1:init) [12:35:33.465016277] libprocessgroup: Successfully killed process cgroup uid 0 pid 5736 in 0ms
ASUS_I006D:/ #
If something does not work execute the script manually in an adb session to check :
Spoiler: /data/recovery/enable_adb_via_service.sh
Code:
ASUS_I006D:/ # rm -f /data/recovery/adb_initialized
ASUS_I006D:/ #
ASUS_I006D:/ #
ASUS_I006D:/ # sh -x /data/recovery/enable_adb_via_service.sh
+ tty -s
+ '[' 0 -ne 0 ']'
+ PATH=/system/bin:/product/bin:/apex/com.android.runtime/bin:/apex/com.android.art/bin:/system_ext/bin:/system/bin:/system/xbin:/odm/bin:/vendor/bin:/vendor/xbin
+ export PATH
+ '[' ! -r /data/recovery/adb_initialized ']'
+ echo 'Sleeping 30 seconds now ...'
Sleeping 30 seconds now ...
+ sleep 30
+ touch /data/recovery/adb_initialized
+ settings put global development_settings_enabled 1
+ settings put global adb_enabled 1
+ '[' ! -d /data/misc/adb ']'
+ '[' ! -r /data/misc/adb/adb_keys ']'
+ '[' -r /data/recovery/adbkey.pub ']'
+ >>/data/misc/adb/adb_keys
+ cat /data/recovery/adbkey.pub
+ '[' -r /data/recovery/adb_temp_keys.xml.human ']'
+ xml2abx /data/recovery/adb_temp_keys.xml.human /data/misc/adb/adb_temp_keys.xml
+ chmod 0600 /data/misc/adb/adb_temp_keys.xml
+ chown system:shell /data/misc/adb/adb_temp_keys.xml
+ chcon -v u:object_r:adb_keys_file:s0 /data/misc/adb/adb_temp_keys.xml
chcon '/data/misc/adb/adb_temp_keys.xml' to u:object_r:adb_keys_file:s0
ASUS_I006D:/ #

Thank you for your explanation, I leave my footprint, I need this sometimes.

How To Guide How to change any file or directory using Magisk

To change a file (or directory) in one of the read-only mounted filesystems in the Android OS Magisk can be used.
(see How to change files in the directory /system with Magisk and How to make files in /system writable )
But this method only works for files in the directories /system, /vendor, /product, or /system_ext.
In current Android OS implementations there are a lot of other directories on read-only filesystems with files that must be changed or replaced to change the behaviour of Android.
For example on some Android implementations the boot animation is in the file /my_product/media/bootanimation/bootanimation.zip. The standard mechanism to change a file on a read-only mounted filesystem via Magisk can not be used to replace this file with another file.
But Magisk also supports executing scripts while booting the phone (see How to run a script at every boot using Magisk)
And the Magisk init scripts in the directory /data/adb/post-fs-data.d are executed early in the boot process. Therefor we can create a Magisk init script to replace any file with another file using the same method Magisk is using (that is a "mount -o bind ..." ):
Note
All commands in this Howto must be done by the user root.
Example
To replace the boot animation with another one copy the ZIP file with the new boot animation to the directory /data/adb (or any other read-write mounted directory available early in the boot process), e.g:
Code:
ASUS_I006D:/data # ls -l /data/adb/Earth_bootanimation.zip
-rw-r--r-- 1 u0_a130 media_rw 13227720 2022-04-16 10:58 /data/adb/Earth_bootanimation.zip
ASUS_I006D:/data #
Make sure that the permissions and SELinux contexts for the file are okay using these commands:
Bash:
chown root:root /data/adb/Earth_bootanimation.zip
chmod 0644 /data/adb/Earth_bootanimation.zip
chcon -v u:object_r:system_file:s0 /data/adb/Earth_bootanimation.zip
Result:
Code:
ASUS_I006D:/data # ls -ldZ /data/adb/Earth_bootanimation.zip
-rw-r--r-- 1 root root u:object_r:system_file:s0 13227720 2022-04-16 10:58 /data/adb/Earth_bootanimation.zip
ASUS_I006D:/data #
Now create a Magisk init script to replace the file via bind mount:
Bash:
echo "mount -o bind /data/adb/Earth_bootanimation.zip /system/media/bootanimation.zip " >/data/adb/post-fs-data.d/change_bootanimation.sh
chmod 755 /data/adb/post-fs-data.d/change_bootanimation.sh
That's it .. Reboot the phone and enjoy the new animation.
To remove the new animation just delete the script /data/adb/post-fs-data.d/change_bootanimation.sh and reboot the phone.
The same method can be used to replace a complete directory using these steps:
e.g. to make the directory /odm/etc writable do:
Bash:
#
# create the new directory
#
mkdir /data/adb/odm_etc
#
# copy the existing files in /odm/etc to the new directory
#
cd /odm/etc && find . | cpio -pdum /data/adb/odm_etc
#
# create the Magisk init script to replace /odm/etc with the new directory /data/adb/odm_etc
#
echo "# make /odm writable
mount -o bind /data/adb/odm_etc /odm/etc
" >/data/adb/post-fs-data.d/make_odm_etc_writable
chmod 0755 /data/adb/post-fs-data.d/make_odm_etc_writable
Now reboot the phone and check the result:
Code:
ASUS_I006D:/ #
ASUS_I006D:/ # ls -l /odm/etc
total 15
-rw-r--r-- 1 root root 4961 2009-01-01 01:00 NOTICE.xml.gz
-rw------- 1 root root 1136 2009-01-01 01:00 build.prop
-r--r--r-- 1 root root 0 2009-01-01 01:00 fs_config_dirs
-r--r--r-- 1 root root 0 2009-01-01 01:00 fs_config_files
-rw-r--r-- 1 root root 0 2009-01-01 01:00 group
-rw-r--r-- 1 root root 0 2009-01-01 01:00 passwd
drwxr-xr-x 2 root root 3452 2023-01-18 16:30 selinux
ASUS_I006D:/ #
#
# create a new file in the directory used to replace /odm/etc
#
ASUS_I006D:/ # touch /data/adb/odm_etc/test.$$
ASUS_I006D:/ # ls -l /data/adb/odm_etc/test.$$
-rw-r--r-- 1 root root 0 2023-01-18 16:41 /data/adb/odm_etc/test.4597
ASUS_I006D:/ #
#
# check the contents of the directory /odm/etc
#
ASUS_I006D:/ # ls -l /odm/etc/test.$$
-rw-r--r-- 1 root root 0 2023-01-18 16:41 //odm/etc/test.4597
ASUS_I006D:/ #
Caution
I'm sure there is a reason why this feature is not implemented for all directories by default in Magisk
And, for example, if you make the directory /odm/etc writable using the method described above Android will complain after the next reboot with an error message that something is wrong with your phone.
Therefor please use with care! If possible only use this approach to make single files writable.
Trouble Shooting
In case the phone does not boot anymore after replacing a file or directory using this method:
Reboot the phone from a recovery with adb support (like TWRP) and delete the script in /data/adb/post-fs-data to fix the error
Notes
Files or directories that are used by Android before the Magisk init scripts are executed can not be changed using this method. These files must be replaced by changing the files in the ramdisk on the boot partition (see How to change files in the boot image using Magisk and How to trigger an action when a property is changed )
There are various Magisk Modules available in the internet to replace the animation that use this technique
To test a boot animation while the Android OS is running do:
Bash:
mount -o bind /data/adb/bootanimation_android12.zip /system/media/bootanimation.zip
bootanimation
Update 24.06.2023/bs
See the post https://forum.xda-developers.com/t/...directory-using-magisk.4543103/#post-88679517 below in this thread for using an overlayfs to make files read-write.

Can it be used to add a self-signed SSL certificate? And also this method works only with ASUS ZenFone 8 or also with others (e.g. OnePlus 9 pro)?

Romano36 said:
Can it be used to add a self-signed SSL certificate? And also this method works only with ASUS ZenFone 8 or also with others (e.g. OnePlus 9 pro)?
Click to expand...
Click to collapse
Hi
Can it be used to add a self-signed SSL certificate?
Click to expand...
Click to collapse
What is the purpose of the new SSL certificate?
If you intend to change the SSL certificate that was used to create the OS :
I did not test this but I'm pretty sure that you can not replace that certificate in an installed OS.
And also this method works only with ASUS ZenFone 8 or also with others (e.g. OnePlus 9 pro)?
Click to expand...
Click to collapse
This method works for all phones and OS that are supported by Magisk.
regards
Bernd

Modded by moderator

Romano36 said:
My purpose is to put a new certificate in this folder /system/etc/security/cacerts/. I have to try.
Click to expand...
Click to collapse
That should work . But I suggest to use a "dummy" Magisk module for that purpose -- see:
How to change files in the directory /system with Magisk
How to change files in the directory /system with Magisk Note: I tested the instructions below with Magisk 24. 25.0, and 25.2 on an ASUS Zenfone 8 running OmniROM (Android 12 ) . The filesystem for /system is normally mounted read-only In...
forum.xda-developers.com
regards
Bernd

Thanks!!!

bnsmb said:
To change a file (or directory) in one of the read-only mounted filesystems in the Android OS Magisk can be used.
(see How to change files in the directory /system with Magisk and How to make files in /system writable )
But this method only works for files in the directories /system, /vendor, /product, or /system_ext.
In current Android OS implementations there are a lot of other directories on read-only filesystems with files that must be changed or replaced to change the behaviour of Android.
For example on some Android implementations the boot animation is in the file /my_product/media/bootanimation/bootanimation.zip. The standard mechanism to change a file on a read-only mounted filesystem via Magisk can not be used to replace this file with another file.
But Magisk also supports executing scripts while booting the phone (see How to run a script at every boot using Magisk)
And the Magisk init scripts in the directory /data/adb/post-fs-data.d are executed early in the boot process. Therefor we can create a Magisk init script to replace any file with another file using the same method Magisk is using (that is a "mount -o bind ..." ):
Note
All commands in this Howto must be done by the user root.
Example
To replace the boot animation with another one copy the ZIP file with the new boot animation to the directory /data/adb (or any other read-write mounted directory available early in the boot process), e.g:
Code:
ASUS_I006D:/data # ls -l /data/adb/Earth_bootanimation.zip
-rw-r--r-- 1 u0_a130 media_rw 13227720 2022-04-16 10:58 /data/adb/Earth_bootanimation.zip
ASUS_I006D:/data #
Make sure that the permissions and SELinux contexts for the file are okay using these commands:
Bash:
chown root:root /data/adb/Earth_bootanimation.zip
chmod 0644 /data/adb/Earth_bootanimation.zip
chcon -v u:object_r:system_file:s0 /data/adb/Earth_bootanimation.zip
Result:
Code:
ASUS_I006D:/data # ls -ldZ /data/adb/Earth_bootanimation.zip
-rw-r--r-- 1 root root u:object_r:system_file:s0 13227720 2022-04-16 10:58 /data/adb/Earth_bootanimation.zip
ASUS_I006D:/data #
Now create a Magisk init script to replace the file via bind mount:
Bash:
echo "mount -o bind /data/adb/Earth_bootanimation.zip /system/media/bootanimation.zip " >/data/adb/post-fs-data.d/change_bootanimation.sh
chmod 755 /data/adb/post-fs-data.d/change_bootanimation.sh
That's it .. Reboot the phone and enjoy the new animation.
To remove the new animation just delete the script /data/adb/post-fs-data.d/change_bootanimation.sh and reboot the phone.
The same method can be used to replace a complete directory using these steps:
e.g. to make the directory /odm/etc writable do:
Bash:
#
# create the new directory
#
mkdir /data/adb/odm_etc
#
# copy the existing files in /odm/etc to the new directory
#
cd /odm/etc && find . | cpio -pdum /data/adb/odm_etc
#
# create the Magisk init script to replace /odm/etc with the new directory /data/adb/odm_etc
#
echo "# make /odm writable
mount -o bind /data/adb/odm_etc /odm/etc
" >/data/adb/post-fs-data.d/make_odm_etc_writable
chmod 0755 /data/adb/post-fs-data.d/make_odm_etc_writable
Now reboot the phone and check the result:
Code:
ASUS_I006D:/ #
ASUS_I006D:/ # ls -l /odm/etc
total 15
-rw-r--r-- 1 root root 4961 2009-01-01 01:00 NOTICE.xml.gz
-rw------- 1 root root 1136 2009-01-01 01:00 build.prop
-r--r--r-- 1 root root 0 2009-01-01 01:00 fs_config_dirs
-r--r--r-- 1 root root 0 2009-01-01 01:00 fs_config_files
-rw-r--r-- 1 root root 0 2009-01-01 01:00 group
-rw-r--r-- 1 root root 0 2009-01-01 01:00 passwd
drwxr-xr-x 2 root root 3452 2023-01-18 16:30 selinux
ASUS_I006D:/ #
#
# create a new file in the directory used to replace /odm/etc
#
ASUS_I006D:/ # touch /data/adb/odm_etc/test.$$
ASUS_I006D:/ # ls -l /data/adb/odm_etc/test.$$
-rw-r--r-- 1 root root 0 2023-01-18 16:41 /data/adb/odm_etc/test.4597
ASUS_I006D:/ #
#
# check the contents of the directory /odm/etc
#
ASUS_I006D:/ # ls -l /odm/etc/test.$$
-rw-r--r-- 1 root root 0 2023-01-18 16:41 //odm/etc/test.4597
ASUS_I006D:/ #
Caution
I'm sure there is a reason why this feature is not implemented for all directories by default in Magisk
And, for example, if you make the directory /odm/etc writable using the method described above Android will complain after the next reboot with an error message that something is wrong with your phone.
Therefor please use with care! If possible only use this approach to make single files writable.
Trouble Shooting
In case the phone does not boot anymore after replacing a file or directory using this method:
Reboot the phone from a recovery with adb support (like TWRP) and delete the script in /data/adb/post-fs-data to fix the error
Notes
Files or directories that are used by Android before the Magisk init scripts are executed can not be changed using this method. These files must be replaced by changing the files in the ramdisk on the boot partition (see How to change files in the boot image using Magisk and How to trigger an action when a property is changed )
There are various Magisk Modules available in the internet to replace the animation that use this technique
To test a boot animation while the Android OS is running do:
Bash:
mount -o bind /data/adb/bootanimation_android12.zip /system/media/bootanimation.zip
bootanimation
Click to expand...
Click to collapse
Hello,
I would like to create a Magisk module that targets the file /odm/etc/mixer_paths.xml.
I am a little confused about the examples you have given. Can you please guide me using the directory I mentioned? It would be very helpful. Thank you.

sargodian2 said:
Hello,
I would like to create a Magisk module that targets the file /odm/etc/mixer_paths.xml.
I am a little confused about the examples you have given. Can you please guide me using the directory I mentioned? It would be very helpful. Thank you.
Click to expand...
Click to collapse
Hi
no Magisk module necessary (but it can be done also via Magisk Module, of course)
Use
- install Magisk
- become root user
- create the file /data/adb/mixer_paths.xml with the changed contents
- create the script /data/adb/post-fs-data.d/change_odm_etc_mixer.sh :
echo "mount -o bind /data/adb/mixer_paths.xml /odm/etc/mixer_paths.xml " >/data/adb/post-fs-data.d/change_odm_etc_mixer.sh
- make the script executable
chmod 755 /data/adb/post-fs-data.d/change_odm_etc_mixer.sh
- reboot
Note that these instructions only work if the file /odm/etc/mixer_paths.xml already exists - you can not create additional files using this approach.
regards
Bernd

bnsmb said:
Hi
no Magisk module necessary (but it can be done also via Magisk Module, of course)
Use
- install Magisk
- become root user
- create the file /data/adb/mixer_paths.xml with the changed contents
- create the script /data/adb/post-fs-data.d/change_odm_etc_mixer.sh :
echo "mount -o bind /data/adb/mixer_paths.xml /odm/etc/mixer_paths.xml " >/data/adb/post-fs-data.d/change_odm_etc_mixer.sh
- make the script executable
chmod 755 /data/adb/post-fs-data.d/change_odm_etc_mixer.sh
- reboot
Note that these instructions only work if the file /odm/etc/mixer_paths.xml already exists - you can not create additional files using this approach.
regards
Bernd
Click to expand...
Click to collapse
Thank You, It worked.

thank you bnsmb
i fallowed your clear steps to modify cscfeature.xml on my S23

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

amk316 said:
View attachment 5938113
Click to expand...
Click to collapse
what's the message of this screenshot?

bnsmb said:
what's the message of this screenshot?
Click to expand...
Click to collapse
when i bind cscfeature.xml on my s23 MemoryDetector app detected it!!!

amk316 said:
when i bind cscfeature.xml on my s23 MemoryDetector app detected it!!!
Click to expand...
Click to collapse
>>when i bind cscfeature.xml on my s23 MemoryDetector app detected it!!!
and do you think that shouldn't be?
I don't know what the MemoryDetector app is used for but is quite easy for an app to check the current mounts to find bind mounts. So it works like expected.
regards
Bernd

Another method to change files in read-only filesystems is to use an overlay filesystem.
This method is implemented in the Magisk Module Magisk Overlayfs.
The source code for this Magisk module is available here:
https://github.com/HuskyDG/magic_overlayfs
Using this Magisk Module every file in most of the read-only filesystems in Android can be changed;
excerpt from the documentation:
Make most parts of system partition (/system, /vendor, /product, /system_ext, /odm, /odm_dlkm, /vendor_dlkm, ...) become read-write.
Click to expand...
Click to collapse
I successfully tested this Magisk Module on an ASUS Zenfone 8 running OmniROM 13.
Notes:
There is no installable zip file in the repository for the Magisk Overlayfs . But the repository contains a script to create the zip file (build.sh).
Note that I had to change the code to create the Magisk module zip file in the script build.sh to create an installable Magisk Module:
I replaced the line
Bash:
zip -r9 out/magisk-module-release.zip out/magisk-module
with
Bash:
cd out/magisk-module && zip -r9 ../magisk-module-release.zip