Disclaymer: I am not responsible by what this binary can cause to your phone.
In the past month I have been struggling with getting "rclone mount" working on my phone, and after not finding anyway to have fuse working on my phone I decided to compile the fusermount.
Yoy should copy the binary to /system/bin or add to your path "export PATH=$PATH:/path_to_fusermount"
I use the source code from: https://github.com/LineageOS/android_external_fuse/tree/cm-14.1
and https://github.com/kirbyfan64/zdata/blob/master/fs/jni/fusermount.mk to compile the binary
In my case I can now use rclone in the following way (you still need to have root access), on a terminal (termux) for android:
Code:
su
rclone mount Box:/ /storage/cloud --vfs-cache-mode minimal --allow-other --gid 1015
Tested on:
Mi4c cm14.1 (android 7.1)
Huawei Mediapad M5 (android 8)
na
Thank you very much. It's so nice that ican mount gdrive on my old phone. Helped me a lot.
Can see my mount point on termux but not see on file manager, please help??
boyrobbie said:
Can see my mount point on termux but not see on file manager, please help??
Click to expand...
Click to collapse
Are you using magisk module based rclone-mount?
darfri said:
Are you using magisk module based rclone-mount?
Click to expand...
Click to collapse
Same with me, I am using magisk module based rclone-mount.
I'm also using magisk module on android 6.0, but I get
Code:
cannot locate symbol "__aeabi_memcpy"
, because of this I can't use this module at all as intended.
Mount folders are created, but are empty. I am able to manually send files to cloud strorage, but they don't show up locally. Also, I can see the mounted folders in bot ES file explorer and Termux.
Edit: Tried it on my other phone running CarbonRom 6.1 (android 8.1.0), and I face the same issue described before me. Termux can list files when cloud storage is mounted, but file explorers show empty folders.
Edit2: Google drive seems to be working on 8.1.0 with Solid Explorer File Manager, mega folder still shows up empty :/
Has anyone got afwall? What to unblock? I'd hate to unblock multicomponent system apps.
Maybe a custom iptables script?
For people who are getting empty folders outside termux, is most likely because mount namespace seperation is enabled in their supersu or magisk. I don't use magisk so don't know the exact option but for supersu, just uncheck "Mount namespace seperation" in its settings and reboot and try after that.
I have successfully done a 64-bit on-device build inside termux for fusermount with the relevant patches. Its working fine for now and most likely will work better for people. I plan to release the binaries, the source code and tasker projects related to it hopefully in the next few days, but if someone needs the binaries earlier, let me know.
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux's. Would it be possible to include arm as well?
Click to expand...
Click to collapse
I initially was attempting a static compile within a ubuntu chroot in my phone but the static flags wouldn't work and it still linked to the "lib/arm-linux-gnueabihf/libc.so" and "/lib/ld-linux-armhf.so.3", which are glibc libs... i then decided to compile within termux itself since people would be using rclone with that anyways and dynamic linkage would hopefully not be a problem. For a 32bit compilation, i would have to look more into it cause that would require 32 libs/compiler dependencies. I tried in the morning but it failed as expected.
i have attached the termux patched source and 64bit fusermount. Instructions for termux compilation are inside the source zip... the source is the same as the OP... If someone could attempt compilation on a 32 bit phone, that would be quicker.
Edit: made some patches and improvements, use new binary.
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Click to expand...
Click to collapse
btw why do u need it outside termux, just curious... if u have root, u could call termux binaries from outside anyways, depending on selinux of course...
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Ah, check it out, looks pretty cool. yeah fixing bugs before bug reports arrive is always appreciated, but if there a no bugs reports that you are fixing with time, then it may look like you are not doing any work
yeah exporting LD_LIBRARY_PATH would work and other than during compilation for makeconf.sh, termux $PREFIX patches are not needed in the source code. The hardcoded binaries are never called if mtab is disabled or platform is not BSD. Also configure.ac does need the $PREFIX patch for setting paths which are read by util/Makefile.am for installing mount.fuse, udev and init.d scripts but those are only needed when "make install" is run and we don't need to run it just to get fusermount. So basically a static compile is possible which does not have hardcoded dependencies on termux binary path, provided that a static compile actually works. You could probabky copy the libs from termux too like you said. I'll have to first have to revert the prefix patches again though.
Few questions, do u sometimes get "transport end point not connected" error while unmounting?
and any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
@agnostic-apollo
do u sometimes get "transport end point not connected" error while unmounting?
Click to expand...
Click to collapse
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
Click to expand...
Click to collapse
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
Click to expand...
Click to collapse
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Geofferey said:
@agnostic-apollo
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Click to expand...
Click to collapse
I'll leave a detailed reply later, its 9 in the morning, i have to sleep now
fyi you can use "ldd util/fusermount" to find the libraries its linking against... and can run "export LD_LIBRARY_PATH=/system/lib64:/system/lib" before running a binary in termux...if it fails with library errors, it requires termux libraries... restart termux or restore LD_LIBRARY_PATH afterwards or other termux stuff wont work...
anyways i did an on-device build of fusermount binary that does not depend on termux/libandroid-support... reverted most of the previous patches and added a few more with new build instructions.... the fusermount binary still depends on /system/lib* libc.so and libdl.so but those are provided by every phone and would run fine on most phones, its basically like the OP one but symbol errors could be there in some devices... truly static might be possible but on device build might not be possible and will probably require cross-compile if even possible... will look into it later
check out the new binary on both devices and let me know...
I am using rclone mount magisk module
It cannot reach the host (its written in the log) when I have "apps running as root" blocked in Afwall
I really hate to allow all root apps to access inet. I would like to allow only rclone access only single local ip
What custom script would help?
It is ordinary iptables script
noob here. but i can follow. how to mount my google drive to my phone alongside to my sdcard i just want to use this as a failsafe to my files, so far i followed the step from rclone using google drive. since some apps has auto backup on phone only and thinking this is the best way to sync my phone and app settings without manually checking and uploading those files. but the problem is im stuck on this error. (screenshot) hope someone can help me. ty
im using magisk rclone module
@Geofferey
Well i managed to cross compile for all archs using NDK targeting API 21. Cannot target an API older than that due to missing function implementation in Android bionic older than that. But binaries will need to be tested on different archs and android versions/devices. You can download the binaries from my github release here. You or others can compile them yourself if they want, instructions are here.
Moreover I still couldn't manage to do a static compile. I doubt it is gonna be possible, atleast easily since Android bionic is probably not meant for that. mucl is the best hope i think, since it fully supports static linking.
However the binaries compiled by me have less library dependencies than the ones OP posted so it could be better for some, even though in OP's case, the binaries are linking to android system libraries so shouldn't be a problem in most cases. FYI I found that "ldd" command is not reliable for finding dynamic linking. Use "readelf -d "fusermount" | grep NEEDED"
The OP binary dynamic linking:
Code:
ARCH=arm64-v8a
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
ARCH=armeabi-v7a
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
The binary dynamic linking compiled by me:
Code:
Build Info:
NDK_FULL_VERSION=20.0.5594570
C_COMPILER=clang
HOST_TAG=linux-x86_64
BUILD_TIMESTAMP=2019-07-31 08.20.46
ARCH_SRC=arm64-v8a
API_LEVEL=21
FUSERMOUNT=fusermount-arm64-v8a
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi-v7a
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi-v7a
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86
API_LEVEL=21
FUSERMOUNT=fusermount-x86
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86-64
API_LEVEL=21
FUSERMOUNT=fusermount-x86-64
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
Alas, the things that need to be done just get binaries to run on our phones properly. If it were only me that had to use fusermount, it wouldn't be a problem at all, i would have just run one my scripts to merge my chroot ubuntu distro's rootfs with my android's rootfs and just run the ubuntu's fusermount and it would have worked fine for me. The ubuntu's libraries would have been dynamically linked to the binary since the ubuntu libraries would be linked to /lib and I wouldn't have to do any compilation at all. Now if it were only this simple for everybody...
Btw i read your previous comments, will try replying to them once i wake up, been too busy with this stuff.
Geofferey said:
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
Click to expand...
Click to collapse
Interesting, I use rclone supplied by termux apt repository. I get the errors if the mount point is busy like root explorer has opened up a directory inside the mount point and I stop the rclone mount command. The rclone mount command exits with resource is busy errors as expected and if i try to unmount the mount point manually i get "transport endpoint" errors, i have run a lazy unmount to get the mount point to unmount.
Geofferey said:
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
Click to expand...
Click to collapse
lolz no apologies needed, I ramble a lot too, not that anybody listens or understands
1. People in most cases are going to put the rclone file once, so going to the magisk module directory should not be a problem.
2. Most apps are granted storage permissions by users in recent android versions, and they are granted without explicit grants in old versions.... /sdcard is basically fuse/sdcardfs mounted to /storage/emulated/0, so all apps having storage permissions would have access to /storage/emulated/0/.rclone and any other directory except the /storage/emulated/0/Android of course... These popular apps are the main security risk tbh, who most likely monitor everything on the sdcard... and selinux wouldn't do anything for sdcard if storage permissions are granted.
And if a person has physical access the then it probably doesn't matter where its stored, but storing it in a root accessible would most likely still be better...
3. You could use the mount command or /proc/mounts to see active mounts to detect what has been mounted till now...
4. Yeah if your threat is a physical access than just keep your bootloader locked and encryption enabled and live a miserable life without all the benefits of rooting. I don't want to live that life, at all... I would be more worried about apps than physical access. And mostly encryption is not supported by twrp so if your device is lost, consider all the data gone if u r using a decrypted device flr using update/backup. Leaving adb enabled normally shouldn't be a problem unless you lose your authorized PC as well, then u probably have much bigger things to worry about
5. I am not familiar with magisk module access but /data/.rclone should be fine to use instead... Only root apps would have access. I'm not sure what selinux contexts magisk module directory has, it might be safer against root apps who have not been granted root access through magisk.
Geofferey said:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Click to expand...
Click to collapse
yeah caching could be hard for the device and will need to be looked over more. Wakelocks would be an issue too. I tried using minimal mode but i need to do more testing. I was getting some lags, might be related. Mobile data issues could be there too, my tasker based projects can most likely handle those by remounting. rclone remote control commands can only drop caches currently, not change their modes. Will need to ask the dev to add it if needed.
Geofferey said:
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
Click to expand...
Click to collapse
yeah I'm up for contributing to the project but only after I have completed and released my projects, gonna take a few days atleast. And yeah i have got github as u already know by now...
lolz C is not for everybody, but thats how I started programming with so I can understand it at most times, understanding the purpose of the code is another issue
Related
I finally found a fix for wired tethering in Linux
A few of you may know that, for some reason, USB tethering with Linux stopped working after the update to Gingerbread. It still works with Windows, but Linux shows a 'bad crc' error in dmesg when USB tethering is activated. But someone figured out a fix, which I finally found and tested. I can confirm that it works with CM7 beta 2 using the built-in tethering option (and I am using it to write this post). The website where I found the patch did not mention what rom it was tested with, but since the patch is for a Linux module on the computer, it most likely won't matter.
Here is the website where I found the instructions - note that you will need to download the patch file, and make sure you have the Linux kernel source (that should be standard, but if you get an error about missing files...). Finally, be sure to pay attention to the punctuation used - code portions containing `uname -r` and M=`pwd` are NOT using the single quote - they are using the symbol located with the ~ (tilde) symbol, and this is extremely important. Anything contained in those symbols will be replaced with their output before execution of the command that contains them - similar to the use of parentheses in algebra.
The command uname -r returns the current kernel revision number, which is used to dynamically direct the commands to the most current source code.
`pwd` resolves to the Present Working Directory
If you prefer a more automated method, I have created a script that follows the commands from the above website, and packaged it with the patch file. Just extract both files into $HOME/Downloads (your Download directory in your home path), and run ./linux-rndis-patcher.sh - you may need to sudo chmod 0755 linux-rndis-patcher.sh first
I hope others find this as useful as I have. I take no credit - my contribution, the script, is a basic copy-and-paste job (tested and confirmed to work on the originating computer).
Update: the process works for the newer 3.2.0 kernel included in Linux 12.04, with slight modifications to match an updated directory structure in the source package. I updated my linux installation only to find that the old problem had returned. I am attaching a copy of the updated script - you can run it (make sure the patch file is in the correct directory) or simply use it as a command list.
Also, I should point out that this does not patch your kernel - it builds a patched stand alone module that can be used to override the built in version. This means it is easy enough to revert the process - more information is contained in the ubuntu wiki linked to from the site where I found the original information
Dude you are awesome, thank you for this!
Sent from my SPH-D700 using xda premium
Minor Correction
Well, I just realized that the script for 3.2 kernels didn't upload, but I can't get to my computer to fix that right now... so in the meantime, anyone who has upgraded to the 3.2 kernel can edit the 3.0 script
Two paths explicitly link to 3.0 directories, the just need to be changed to 3.2
Also, the path within the source code tree has changed - I will edit this post with the correct path momentarily, so stay tuned...
EDIT: I'm not sure what I was thinking about the path, but everything should be fine once both instances of "linux-source-3.0.0..." are edited to "...source-3.2.0"
Oh, and I renamed the patch file, so be sure to use the correct filename based on whether you download directly from the source or use the copy in my upload (identical aside from the filename)
Sent from my SPH-D700 using XDA
To clarify the bug here, the problem is that the Samsung Gingerbread USB gadget stack misspecifies a USB CDC union descriptor configuration that doesn't match what the device actually uses in RNDIS mode.
Windows, apparently, either ignores or doesn't care about the misconfiguration. Linux, while it's capable of detecting RNDIS interfaces in the absence of a CDC union description entirely, is "too strict" when the configuration is misspecified. So this patch makes Linux less strict in this regard.
So in short, the actual bug is in the device's kernel. But since RNDIS behavior is pretty much defined as "whatever Windows tolerates", it's reasonable and prudent to fix it on Linux USB hosts as well.
In any event, there's a few patches floating around for custom kernels to fix this problem on the device side, which is preferable as we don't really want to have to patch every Linux machine out there to deal with this issue. The one that we implemented for the CM9 kernel is here, and should've been included in our CM9 builds since alpha3 I believe.
Too true, I just haven't gotten around to figuring out how to patch the CM7 kernel yet so this works for me. Thanks for explaining the bug, so others will be aware that this is a workaround, not really a fix... I'll change the thread title, now that I think about it
Sent from my SPH-D700 using XDA
Yeah, there's a few changes in the CM9 kernel that need to be backported to CM7. Tortel is working on that now actually, so hopefully the next CM7 release will include the RNDIS fix among others.
Inspired by SimpleSU (I really love it), which is not so simple to use after all (mainly because it is intended for shipping in the ramdisk or the likes), and closed source, I made my own superuser implementation, µSuper.
I provide it to you, mainly so you can give me some feed back or just try it, whatever you prefer.
Just like SimpleSU it uses a text file.
Unlike SimpleSU this text file contains the UIDs of the apps, not their package names (which makes µSU less vulnerable to frauds). It is also not on the hard to access /system partition, but in the private data directory of µSU, and globally set to read-only.
With only 309 SLOC (app and binary combined) I think it is safe to say that it is really tiny.
The source code is publicly available on Github.
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
HTCDreamOn said:
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
Click to expand...
Click to collapse
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Aiko0923 said:
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Click to expand...
Click to collapse
I see your point but I still stick with this SU: SuperSU is closed source, and even Koush' open source Superuser app is theoretically less secure than this, due to the whole granting mechanism; with µSuper the user must explicitly select which apps gain su access whether they ask for it or not, and the code is so small there's little which could go wrong. Each to their own, though , I use this because the Desire Z is lacking in memory and CPU power so every little helps, but on a more powerful device it wouldn't bother me.
HTCDreamOn said:
I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Click to expand...
Click to collapse
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
MarcoToo said:
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
Click to expand...
Click to collapse
Forked and synced let's see if I can fix this for later versions I don't suppose you'd know how to implement this into a ROM (using source code)? From the README I assume I'm allowed to
e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.
Unfortunately, my device is armv7
buengeut said:
Unfortunately, my device is armv7
Click to expand...
Click to collapse
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
ARMv7 is ARM 32bit, 64bit program will not work on a 32bit system.
Can you build e2fstools for ARMv7.
Sadly your link is down.
would you care to reupload?
LNQ said:
Sadly your link is down.
would you care to reupload?
Click to expand...
Click to collapse
Sure. I'll even make it flashable this time ?
Thanks alot, good sir!
Legend! I'd been dealing with not being able to repair my /data errors for the past few days since my Oreo update. The current TWRP (3.2.3.4) still has an ancient e2fsck that doesn't support the ext4 quota option that LG formats their Oreo data partition with. The updated version in /system/bin works while the OS is running which is why I knew I had errors, but I couldn't get it to run in TWRP to fix them because of the incompatible library files.
I was all set to reinstall my Android SDK and compile another version with inbuilt libraries when I decided to do one last search and found this thread where you'd already done it. So thanks for saving me a few hours of downloading/installing/remembering how to compile for Android all over again
I guess I can also vouch for it working on an LG V20. I don't know if it's just LG's version of Oreo that needs the later e2fsck or others too, but anyone who can't repair errors on their ext4 partitions in TWRP due to needing a newer e2fsck version should be able to use this version. I just copied the file fsck.ext4dev to /cache and ran it from there on my data partition.
Your link is dropbox banned...
Any chance you could attach the zip here...?
quotient said:
Your link is dropbox banned...
Any chance you could attach the zip here...?
Click to expand...
Click to collapse
Seconded!
@partcyborg
Any chance you could put this file somewhere else? The above link is banned.
Thanks!
Hi,
I have a Oneplus 3 that after 3 years of use became sluggish as hell at file system access.
After reading thus document https://www.usenix.org/system/files/conference/hotstorage16/hotstorage16_ji.pdf
I would give a try to your e2fstools build.
Can you repost a link to download?
Thanks in advance
partcyborg said:
I forget, is that 32bit? If so i could fairly easily build new ones that are 32bit. Did you try them and they didnt work? If its 64bit they may work anyway, as these dont use any fancy instructions, and i did not build them even with -O1. I thought the main differences between the different "v"s of the same arch (32v64) was in libc and friends, of which these dont use as they are completely static so libc is built in.
I was even thinking of making this a flashable zip, but i hadnt bothered as no one replied to my initial post so i didnt think anyone cared ?️
Click to expand...
Click to collapse
Late to this thread, great work!
I have the exact same problem.
Could you please post flashable zip and/or instructions how to load this into android?
Thank you
I found a binary on website, tested on Nexus 5 (ARMv7L 32bits)
GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
Static build of e2fsprogs for Android Magisk Module - GitHub - FerryAr/e2fsprogs-arm: Static build of e2fsprogs for Android Magisk Module
github.com
partcyborg said:
e2fstools package, statically built for arm64 devices from Google's googlecode.com Oreo branch
NOTE: These will support ANY version of android's filesystems that use ext2 or ext3 or ext4. I built them from oreo branch as that one was the closest to compiling without any editing of the Makefiles. Don't let the name throw you off
I needed to run a modern fsck on a rooted device I have that I have been doing some hacking on.
The filesystem was in bad shape and the on-device e2fsck absolutely refused to check it while it was even mounted, even with the force option. Out of part desperation part determination I decided I would just build one myself. So I went and dug up the sources from googlecode.com, transfered them to my linux workstation, and after much fighting with gcc for cross compilation, finding a place in the google git repo where they actually build (hence going with orero), and having to tweak the c code even in a few places (mostly fixing includes and whatnot, no actual coding on my part), I succeeded.
As it says in the title, these are all the e2fstools binaries built from Google's googlecode.com source tree in their Oreo release branch. They are also compiled statically (no libraries are needed for them to function) so they should work absolutely fine on any device that has a 64bit arm (aarch64) processor. I have tested a handfull of them and they work perfectly fine on my Samsung Galaxy s8. In fact I used the fsck.ext4 binary to repair my system partition which it did perfectly.
https://www.dropbox.com/s/owb76hohnjzjdwe/e2fstools-oreo-aarch64-static.tar.gz?dl=0
Hope they come in as handy to someone else as they did me.
List of files follows:
Code:
[email protected]:~> tar tzf e2fstools-oreo-aarch64-static.tar.gz
e2fsbin/
e2fsbin/e2undo
e2fsbin/e2image
e2fsbin/badblocks
e2fsbin/mkfs.ext3
e2fsbin/fsck.ext4dev
e2fsbin/e2initrd_helper
e2fsbin/fsck.ext3
e2fsbin/e4crypt
e2fsbin/e4defrag
e2fsbin/mke2fs
e2fsbin/e2fsck
e2fsbin/fsck.ext4
e2fsbin/filefrag
e2fsbin/tune2fs
e2fsbin/e2freefrag
e2fsbin/uuidd
e2fsbin/e2label
e2fsbin/mkfs.ext2
e2fsbin/blkid
e2fsbin/logsave
e2fsbin/lsattr
e2fsbin/uuidgen
e2fsbin/findfs
e2fsbin/mklost+found
e2fsbin/dumpe2fs
e2fsbin/mkfs.ext4
e2fsbin/debugfs
e2fsbin/fsck.ext2
e2fsbin/mkfs.ext4dev
e2fsbin/resize2fs
e2fsbin/chattr
e2fsbin/fsck
PS: Now that I have a working arm64 cross compilation system setup, if anyone else desperately needs a working static binary for anything relatively simple to build (as in not 50 million dependencies for me to track down and install) and can send me or link me the sources for it and its dependencies, I would be happy to oblige.
Click to expand...
Click to collapse
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!
lebigmac said:
Hi nice compilation job! I know it's not always easy to compile these binaries from source...
Can you please reupload you archive here as attachment? Thanks!
Click to expand...
Click to collapse
There's a Magisk module that does cross-compilation specifically, you should get it.
By the way, the link for that drop box is dead.
Hello everyone.
Can we please get root on this phone?
Specs are:
Operating System: KaiOS
System chip: Qualcomm Snapdragon 205 MSM8905
Processor: Dual-core, 1100 MHz, ARM Cortex-A7, 32-bit, 28 nm
Graphics processor: Adreno 304
System memory: 0.5 GB RAM
Built-in storage: 4 GB
Storage expansion: up to 64 GB
sgmarouf said:
Hello everyone.
Can we please get root on this phone?
Specs are:
Operating System: KaiOS
System chip: Qualcomm Snapdragon 205 MSM8905
Processor: Dual-core, 1100 MHz, ARM Cortex-A7, 32-bit, 28 nm
Graphics processor: Adreno 304
System memory: 0.5 GB RAM
Built-in storage: 4 GB
Storage expansion: up to 64 GB
Click to expand...
Click to collapse
Im also wondering the same thing
Yes, have been able to flash my own system and it is also possible to get ADB.
I am currently working on it, but it might take some days to get something useful out of it. As I just created a new account here, I am currently not able to post any links, but you can find my stuff linked on Twitter via @nexus511.
nexus511 said:
Yes, have been able to flash my own system and it is also possible to get ADB.
I am currently working on it, but it might take some days to get something useful out of it. As I just created a new account here, I am currently not able to post any links, but you can find my stuff linked on Twitter via @nexus511.
Click to expand...
Click to collapse
Good job! :good:
0312birdzhang said:
Good job! :good:
Click to expand...
Click to collapse
Short update:
I have been able to gain root and I have also been able to modify selinux policies on the device. Then I have been running into some strange behavior. It actually looks like the kernel is telling to be running in permissive mode but even a permissive context seems to be enforcing instead.
I will try to use something like "Magisk" instead and see, if a service can solve this issue.
For anyone interested: The kernel-config can be extracted via /proc/config.gz. The dtb is compiled into the kernel image. Maybe I try extracting the dtb and building a codeaurora kernel for the device and see, how far I get with that. This might resolve the strange selinux issues I currently see.
nexus511 said:
Short update:
I have been able to gain root and I have also been able to modify selinux policies on the device. Then I have been running into some strange behavior. It actually looks like the kernel is telling to be running in permissive mode but even a permissive context seems to be enforcing instead.
I will try to use something like "Magisk" instead and see, if a service can solve this issue.
For anyone interested: The kernel-config can be extracted via /proc/config.gz. The dtb is compiled into the kernel image. Maybe I try extracting the dtb and building a codeaurora kernel for the device and see, how far I get with that. This might resolve the strange selinux issues I currently see.
Click to expand...
Click to collapse
This is a good news! I just bought a "banana" today, waiting for your good news :fingers-crossed:
nexus511 said:
Short update:
I have been able to gain root and I have also been able to modify selinux policies on the device. Then I have been running into some strange behavior. It actually looks like the kernel is telling to be running in permissive mode but even a permissive context seems to be enforcing instead.
I will try to use something like "Magisk" instead and see, if a service can solve this issue.
For anyone interested: The kernel-config can be extracted via /proc/config.gz. The dtb is compiled into the kernel image. Maybe I try extracting the dtb and building a codeaurora kernel for the device and see, how far I get with that. This might resolve the strange selinux issues I currently see.
Click to expand...
Click to collapse
Sounds like you've made some impressive progress here, can't wait for more details!
Will you be posting a more detailed tutorial/how-to here or on your blog in the future?
Keep up the great work! :good:
Great work, would be great to uninstalled preinstalled *tty demo games.
@nexus511, any way you could please share the root procedure or point to some resources?
Or...at the very least when you get a spare second, how you did manage to unlock your bootloader knowing Nokia has publicly acknowledge disabling Device > Developer?
Muchas,
nexus511 said:
Short update:
I have been able to gain root and I have also been able to modify selinux policies on the device. Then I have been running into some strange behavior. It actually looks like the kernel is telling to be running in permissive mode but even a permissive context seems to be enforcing instead.
I will try to use something like "Magisk" instead and see, if a service can solve this issue.
For anyone interested: The kernel-config can be extracted via /proc/config.gz. The dtb is compiled into the kernel image. Maybe I try extracting the dtb and building a codeaurora kernel for the device and see, how far I get with that. This might resolve the strange selinux issues I currently see.
Click to expand...
Click to collapse
fpb4 said:
@nexus511, any way you could please share the root procedure or point to some resources?
Or...at the very least when you get a spare second, how you did manage to unlock your bootloader knowing Nokia has publicly acknowledge disabling Device > Developer?
Muchas,
Click to expand...
Click to collapse
Use OmniJB can enable "Developer Mode".
Tested on sideload mode
0312birdzhang said:
Use OmniJB can enable "Developer Mode".
Tested on sideload mode
Click to expand...
Click to collapse
Cheers mate :good: , that's a step forward (and cookie points to OmniJB's dev for the firefox 52.9 esr trick) - now WebIDE lists all runtime apps in Unrestricted DevTools privileges...which is great should I be willing to debug any of those or create my own. What I am looking for though is a way to *delete/un-install/remove* (no cigar remounting /system/b2g/webapps rw without root) some of the certified pre-installed applications (assistant to start with or the bunch of packaged Gameloft bloatware). Any idea - i've pm'ed @nexus511 for some root procedure but no answer yet?
0312birdzhang said:
Use OmniJB can enable "Developer Mode".
Tested on sideload mode
Click to expand...
Click to collapse
Is there anyway I could revert installing omniJB? I'd love to be able to install factory updates again.
hello all, just give an update on how's everything regarding nokia 8110 is going
fpb4 said:
Cheers mate :good: , that's a step forward (and cookie points to OmniJB's dev for the firefox 52.9 esr trick) - now WebIDE lists all runtime apps in Unrestricted DevTools privileges...which is great should I be willing to debug any of those or create my own. What I am looking for though is a way to *delete/un-install/remove* (no cigar remounting /system/b2g/webapps rw without root) some of the certified pre-installed applications (assistant to start with or the bunch of packaged Gameloft bloatware). Any idea - i've pm'ed @nexus511 for some root procedure but no answer yet?
Click to expand...
Click to collapse
Could you remove the pre-installed apps?
Hi!
It's possible, to get full ADB-Root by injecting a patched adbd-binary. And with real swap instead of zram, the device is more responsive (background-tasks like Launcher/Homescreen are killed less often...)
As soon, as I have build my own patched adbd, I will provide an 'update.zip' -- it seems chainfire doens't like others to use his version. (OpenSource -- anyone? )
BTW: no, I don't have 'su' -- only my own priviledged additional startscript and ADB-Root but for me this is more than enough to 'work'
(my goal is to create native apps with Ada/Gnoga - meaning native but with HTML5-GUI. First tests are working well...)
I would love to have this phone without the pre-installed social media and game garbage, would your planned update.zip allow someone reasonably competent at following instructions to do this easily or is experience required?
It should be possible to remove those apps - but for me it's hard to say how. On my device there were no preinstalled apps/games other than snake. Everything else is (un)installable normally. Could be a region-thing
(I've got the european/german version)
-- but on my device the store seems to be a 'static' bunch of zips - so it could kill the store to just remove those.
(i think I would need to adjust configs for the store if I want to clean them up)
If I remember correctly, there is a flag in the app-manifest to config if an app is removeable... my first try would be to edit this flag and check if I could uninstall it normally after this
On the other hand: there is nearly no need to uninstall - KaiOS-Apps are small and with a sdcard....
(I created an extra 1GB-Swap on /data - even then enough space left)
BTW: if You have a little experience with android-stuff, rooting is simple when You know how
Enable adb --> just type *#*#33284#*#* on keypad of your phone (the digits spell 'debug' )
-- build an update.zip - sign with AOSP-Test-Keys
--- let it create '/data/opt', '/data/opt/bin'
--- put an patched adbd (chainfire's v22 works) in /data/opt/bin
--- create /data/opt/init as a shellscript, remounting / rw, replace /sbin/adbd with patched one, remount / ro kill adbd so it restarts the patched version. (you may add commands for other stuff on boot - I disable zram, enable swapfile, start en Ada-Server....)
--- and add a call to '/data/opt/init' as last line to '/etc/init.qcom.post_boot.sh' so this 'init' will start with root-rights on startup.
This way /data/opt/init will inherit root from /etc/init.qcom.post_boot.sh, so it can replace adbd - and because the patched version won't drop it's root-rights you'll have a root shell over adb.
As You see - it's quite trivial, but at the moment I don't have a patched adbd which I'm allowed to include.
(I hadn't time to build an AOSP-tree until now)
Has anyone tried installing OmniJB from 4pda.ru website? (Sorry can't post links)
If you google "4pda 890710" it will bring it up.
Also, anyway of installing whatsapp yet?
PolePolisher said:
I would love to have this phone without the pre-installed social media and game garbage, would your planned update.zip allow someone reasonably competent at following instructions to do this easily or is experience required?
Click to expand...
Click to collapse
root or create an update to edit /data/local/webapps/webapps.json
it worked on my phone no more s*** games and google stuff
Can I not just replace the /sbin/adbd from the boot.img?
(by extracting the boot.img with a flashable zip, and then unpack/repack with kitchen)
So the idea here is to re-map file shares as data paths for the provided device. Why? Because not every device was manufactured to have 256gb of storage and we now have things like popcorn time, netflix and other various services that allow you to download to your mobiledevice/pc. Most app's are defaulting to the internal SD card if not within their data folder to save/cache files. Yes SD cards are super cheap now adays and are bigger but a 4tb disk platter is still by far the best value and does not cost you $1000+ as the sd card probably would.
The goal? To delete that static folder each app uses and either create a symbolic link/mount bind the the CIFS share so files that are written to disk end up on the shared storage. The alternative I suppose is to re-compile each app to use a different path but that is going to be much more tedious and maintenance in the long run.
So comes to the part of why I am posting on XDA regarding this. I'm more ops/networking/security background than a actual dev and seem to need a little push in the right direction to accomplishing this. I currently have a Android 6.0.1 tablet and galaxy s8 to fiddle with. They are rooted which is a pre-req for this as well need to load kernel modules to support CIFS shares. The android 6.0.1 does not have CIFS support along with Android 9 on the S8. The requirements to get this functional would be loading CIFS.KO, busybox, and root access. Currently I'm having issues as to how to compile cifs.ko as its apart of the linux kernel. Any insight, links or comments as to how to proceed would be appreciated. I'm unsure if I need the source to the ROM currently running and rebuild the kernel of that to include the modules or if I can somehow compile the module and use insmod to load them at boot. Is it as simple as compiling the linux kernel version I currently run from uname -a and to migrate the cifs.ko module from that?