So I have rooted my Nexus 6p with Magisk v13. Confirmed it worked as I have several apps with SU authority. I'm trying to install V4A. In order to get it to work I need to rename audio_effects.conf in /Vendor/Etc. I'm getting permission issue. How do I mount to get permission? Tried several ways: downloading remount app, using terminal emulator, using adb shell. Not sure what I'm doing wrong. I used to be have permission when I used old systemless root + SuperSU for root.
synnyster said:
So I have rooted my Nexus 6p with Magisk v13. Confirmed it worked as I have several apps with SU authority. I'm trying to install V4A. In order to get it to work I need to rename audio_effects.conf in /Vendor/Etc. I'm getting permission issue. How do I mount to get permission? Tried several ways: downloading remount app, using terminal emulator, using adb shell. Not sure what I'm doing wrong. I used to be have permission when I used old systemless root + SuperSU for root.
Click to expand...
Click to collapse
Just use this and the add ons like JamesDSP. The sound is much better than viper in my opinion.
https://forum.xda-developers.com/android/software/soundmod-ainur-audio-t3450516
Never had this issue with magisk, may you do a clean install, maybe it's magisk, maybe the rom, maybe your Explorer. Anyway, if you only want to rename the file, do it with twrp, boot twrp, mount system, vendor whatever you want to and rename the file with the twrpfilemanager, this will always work.
Related
So, I'm rooted. S=OFF, I get su access in Terminal, and I have the latest busybox installed in /system/bin. But, after a reboot of the device I can only get R/W access to certain parts of the directory structure - /system is unfortunately not one of them.
Now, here's the weird part: When I start the app Busybox Installer (downloaded from the market), the app searches for busybox installations and tells me I have the latest in /system/bin (this I already know). Once I have started this Installer without doing anything else, I can gain full R/W access to /system.
So, there seems to be some sort of strange busybox issue and how it relates to system R/W access. Is the latest busybox incompatible with this stock ROM?
Root explorer issues
I am also having the same issue I can not get R/W access in the system folder. I have been trying to re-map the Genius button. I am able to remove "bloatware" by using Titanium backup. I definitely have permanent root on the phone, so I am confused by this issue. I have been searching and have not seen other similar complaints. I tried the busybox from the above post but still am not able to R/W access.
You need the latest version of root explorer. Will solve the issue.
Sent from my HTC Glacier
I'm running cm7 Barebones on my KF and I've read that SuperSu is supposed to be "better" than regular SuperUser. First, can anyone confirm/deny this? Second, Is it ok to have both installed simultaneously? I can't seem to find a way to uninstall SuperUser. It isn't listed in Titanium backup(SuperSu is) and Settings-->Applications-->Manage Apps only allows me to force stop but not uninstall. Any help/input/comments would be appreciated. Thanks in advance.
Hi, you can remove superuser by deleting /system/app/superuser.apk (I'm assuming SuperSU overwrites /system/bin/su and busybox) and then rebooting. You may use ADB, Root Explorer, ES File Explorer with Root permissions mounting /system as writeable...
As for whether SuperSU is better, that's up to each individual's circumstances. It's best if you read a bit more about the features SuperSU has and then decide on your own: http://forum.xda-developers.com/showthread.php?t=1538053
Hi all,
Ive spent to weekend reading about rooting and ROMS/Kernels and decided to try it. I used a root kit found here from Mskip (great kit). Ive sucessfully rooted, and then sucessfully installed Smooth Rom 4.3 with the Motley kernel.
Ive downloaded Titanium Backup and Rom Manager. TB worked and I did a backup (which I now cant find) (i have ES File Explorer). I upgraded to Titanium Pro, and now when I open the app is states root was denied. I remember when I first opened TB SuperSu asked me to grant it access. After a reboot I opened SuperSu and stated a Binary update was necessary and performed it.
Now TB pro states root was denied, when I open SuperSu there is nothing there in the apps list, and I dont know how to manually grant TB root access.
Sorry if this is noobish, not sure what to do and I dont want to keep going without a backup.
Edit: When I try to backup in ROM Manager I hit backup, it brings up the notification to name the backup, I hit ok and nothing happens.
cam75 said:
After a reboot I opened SuperSu and stated a Binary update was necessary and performed it.
Now TB pro states root was denied, when I open SuperSu there is nothing there in the apps list, and I dont know how to manually grant TB root access.
Click to expand...
Click to collapse
That sort of sounds like the SuperSU "su" update might have failed. Can you get root with other apps? (e.g. go in to a terminal emulator and type "su")
Note there is a chicken-and-egg problem if (either) SuperSU/su or Superuser/su fail: they need root themselves to remount /system so that the "su" binary can be updated.
If no apps can get root, then you sort of have "lost root", and the fix is to manually insert the .apk and su binary into /system/app and /system/bin/su (or /system/xbin/su depending on flavor!) either with a flash package in recovery, or manually via the adb shell command line (with custom recovery running).
HTH
PS you should be able to just manually start the recovery and do a backup in the meantime, no? The fact that ROM manager isn't doing anything could either be a lack-of-root problem or something else (a busybox dependency?)
bftb0 said:
That sort of sounds like the SuperSU "su" update might have failed. Can you get root with other apps? (e.g. go in to a terminal emulator and type "su")
Note there is a chicken-and-egg problem if (either) SuperSU/su or Superuser/su fail: they need root themselves to remount /system so that the "su" binary can be updated.
If no apps can get root, then you sort of have "lost root", and the fix is to manually insert the .apk and su binary into /system/app and /system/bin/su (or /system/xbin/su depending on flavor!) either with a flash package in recovery, or manually via the adb shell command line (with custom recovery running).
HTH
PS you should be able to just manually start the recovery and do a backup in the meantime, no? The fact that ROM manager isn't doing anything could either be a lack-of-root problem or something else (a busybox dependency?)
Click to expand...
Click to collapse
thx for the quick response, however much of that is WAY over my head. I opened terminal emulator and typed su and this is what popped up. 1 [email protected]:/ $
When TB is opened it states error "sorry I could not acquire root privilegdes. this applidation will not work. please verify that your rom is rooted and try again. this attempt was made using the "/system/xbin/su" command.
I dont see busybox in my app drawer
cam75 said:
thx for the quick response, however much of that is WAY over my head. I opened terminal emulator and typed su and this is what popped up. 1 [email protected]droid:/ $
Click to expand...
Click to collapse
If the SuperSU app (and companion binary) were working correctly, you should have seen one of those "Accept / Deny" pop-up messages coming from the SuperSU app... assuming that you didn't previously grant root access to that terminal emulator app. You didn't mention that happening.... ?
Also, usually the command prompt usually changes from $ to # when you have root, but not always; the explicit way to check would be to (after you have tried the "su" command) to type in "id" and hit return at the prompt - that will tell you explicitly if you are root or not. (That's the letter "i" followed by the letter "d" followed by the return key).
From the way you describe this, it is sounding like you lost root.
I gotta go watch part of the game. In the meantime, perhaps you should at least create a backup manually.
As I said, the simplest fix-up would be to get Superuser.apk/su or SuperSU/su re-installed into /system/app and /system/{x}bin/su (it seems that chainsDD and chainfire use different locations).
There might be floating around someplace a flashable zip file with this stuff in it - to be used for "lightly rooting" a stock ROM after a custom recovery is in place. But things have been in flux recently with both the SuperSU (chainfire) and Superuser (chainsDD) kits because of the JellyBean multi-user support, so the version you might need is important. So you would have to do the research to figure out where.
gotta go - good luck.
bftb0 said:
If the SuperSU app (and companion binary) were working correctly, you should have seen one of those "Accept / Deny" pop-up messages coming from the SuperSU app... assuming that you didn't previously grant root access to that terminal emulator app. You didn't mention that happening.... ?
Also, usually the command prompt usually changes from $ to # when you have root, but not always; the explicit way to check would be to (after you have tried the "su" command) to type in "id" and hit return at the prompt - that will tell you explicitly if you are root or not. (That's the letter "i" followed by the letter "d" followed by the return key).
From the way you describe this, it is sounding like you lost root.
I gotta go watch part of the game. In the meantime, perhaps you should at least create a backup manually.
As I said, the simplest fix-up would be to get Superuser.apk/su or SuperSU/su re-installed into /system/app and /system/{x}bin/su (it seems that chainsDD and chainfire use different locations).
There might be floating around someplace a flashable zip file with this stuff in it - to be used for "lightly rooting" a stock ROM after a custom recovery is in place. But things have been in flux recently with both the SuperSU (chainfire) and Superuser (chainsDD) kits because of the JellyBean multi-user support, so the version you might need is important. So you would have to do the research to figure out where.
gotta go - good luck.
Click to expand...
Click to collapse
Thanks again.
Im watching Superbowl as well. I didnt grant Terminal access. I rebooted into recovery and restored to right after I rooted. SuperSu auto updated through the play store, and stated the binary need updated. I canceled that. TB and ROM manager are showing up in SuperSu. So now Im rebooting into recovery again to after I installed the Smooth Rom/Motley Kernal. I did make a backup of where SuperSu lost root. I now have three backups.
Question on installing the SuperSu apk file. I want to be sure I do it right, if needed. Download the file on my 7. it will go to my download folder. Move it to the system folder and open/run it? what do i do with the current SuperSu folder?
thanks again
I went to my restore point after root and reinstalled 4.3 Smooth ROM Mkernel. I did not take the SuperSu update, (ill wait for the next update) and everything is fine TB an ROM manager working fine, did a backup in both.
Thanks for your help on this.
cam75 said:
Question on installing the SuperSu apk file. I want to be sure I do it right, if needed. Download the file on my 7. it will go to my download folder. Move it to the system folder and open/run it? what do i do with the current SuperSu folder?
Click to expand...
Click to collapse
Dealing with .apk's is not that difficult - drop them into the correct place and reboot.
In Android, apps (.apk files) are stored in one of two places: /system/app or /data/app. It is even possible for two versions of an app to be on the phone - one in /system/app and one in /data/app; that is how upgrades of factory-installed apps happen: the pre-installed app is in /system/app... and never gets deleted (read-only filesystem), whereas update versions get dropped into /data/app. Generally you can just drop an .apk file into either of these locations, wipe the dalvik cache and reboot. During the android boot, these files are compiled into .dex objects in the dalvik-cache, and various version, consistency, rights and permissions are cross-checked.
Think of it this way: when you boot a new ROM for the first time, /data starts out completely empty. Everything needed to support each pre-installed app in /system/app gets created automatically during the android layer start-up.
The "su" native binary is a bit more complicated - it needs to be:
- owned by the user.group root.root
- be executable
- be setuid/setgid
Imagine that you had a copy of these two files on your "/sdcard". If you booted into the custom recovery, you could affect these changes like this:
C:\foo> adb shell
# mount # show what is already mounted
# mount /sdcard # if needed
# mount /system # if needed
# mv /system/app/SuperSU.apk /system/app/SuperSU.apk.old
# cp /sdcard/SuperSU.apk /system/app/SuperSU.apk
# mv /system/xbin/su /system/xbin/su.old
# cp /sdcard/su /system/xbin/su
# chown root.root /system/xbin/su
# chmod 6755 /system/xbin/su
# cd /
# umount /system
# exit
C:\foo>
*
As a practical matter, it is probably easier to just make sure to make a fresh backup if you are about to update the su binary - in case anything goes wrong. It might also be useful to use a root-aware file manager to remount the /system partition in rw mode prior to doing the "update su binary" procedure in the SuperSU app.
Good luck
* note that SuperSU and Superuser apps choose different locations for the su executable file - one uses /system/bin/su and the other /system/xbin/su. There might also be a symlink between these locations. Best policy is probably to examine a known-working installation to determine how to proceed.
I've flashed the latest Android 5.0 build (LRX21T) to my Nexus 4 using the flash-all script. Then I flashed CF-Auto-Root for build LRX21T using the root-windows script. I now have the SuperSU app installed and I can grant superuser permissions.
The problem is that apps that require root don't really seem to get root, even if I granted superuser permissions. Some apps just get stuck, some give error messages and others just don't do anything. I also can't remount /system as rw myself using a terminal emulator. I've installed BusyBox in both /system/xbin and /system/bin, but it's still not working.
Apps that don't work: ES File Explorer, Cabinet, App Eater, Build Prop Editor, Root Uninstaller...
I just want to edit my build.prop and delete some system apps. Does anyone have the same problem or knows a way to at least edit build.prop?
Thanks!
The issues in this thread are similar to my issue, but I can't find a solution there.
Before I get started, let me say that I love Magisk. It's a great app and works beautifully . . . about 99 44/100% of the time.
I also love Link2SD Pro. It's my go-to app not just for linking apps to my SD card, but for freezing and unfreezing apps, moving things in and out of /system, and just generally cleaning and debloating my tablet.
Unfortunately, the two don't work and play nicely on my Fire HD 10 (2017 edition running Fire OS 5.6.4.0 from March 2019). Link2SD relies on having an 'su' program available to do its magic and launches 'su' behind the scenes when it starts up. I verified this in two ways:
1. If I do 'ps' while Link2SD is running it shows that it opens a 'su' session, which in turn spawns a '/system/bin/sh' session owned by root.
2. If I hide Link2SD in Magisk Manager, it tells me it can't get root access.
Why is this important? Because whenever I try to get Link2SD to do anything that requires root access, it throws an error message that says 'CANNOT LINk EXECUTABLE DEPENDENCIES: "libandroid_runtime.so" is 64-bit instead of 32-bit.' This doesn't happen on my Fire HD 8s running 6.3.0.1.
I tried copying mtk-su, which gives me root access if I run it directly, into /system/xbin and creating a symbolic link to it with 'ln -s mtk-su su'. I was able to get a root prompt in the Fire OS shell by executing /system/xbin/su, but when I tried hiding Link2SD in Magisk Manager so it would (hopefully) open su from /system/xbin, which is at the end of my $PATH . . . nothing. I got the Spinning Wheel Of Death and Link2SD never launched. Apparently it was trying to launch mtk-su (as just 'su') behind the scenes and wasn't able to do so, or was waiting for something else to give it permission, or . . . well who knows.
So here I am. I think if I had an su binary that wasn't just a symlink to 'magisk', and that used the libraries in /system/lib, I could drop it into /system/xbin and Link2SD would fire it up if I hid Magisk from it. Any suggestions?
Thanks in advance.
NerdFire said:
Before I get started, let me say that I love Magisk. It's a great app and works beautifully . . . about 99 44/100% of the time.
I also love Link2SD Pro. It's my go-to app not just for linking apps to my SD card, but for freezing and unfreezing apps, moving things in and out of /system, and just generally cleaning and debloating my tablet.
Unfortunately, the two don't work and play nicely on my Fire HD 10 (2017 edition running Fire OS 5.6.4.0 from March 2019). Link2SD relies on having an 'su' program available to do its magic and launches 'su' behind the scenes when it starts up. I verified this in two ways:
1. If I do 'ps' while Link2SD is running it shows that it opens a 'su' session, which in turn spawns a '/system/bin/sh' session owned by root.
2. If I hide Link2SD in Magisk Manager, it tells me it can't get root access.
Why is this important? Because whenever I try to get Link2SD to do anything that requires root access, it throws an error message that says 'CANNOT LINk EXECUTABLE DEPENDENCIES: "libandroid_runtime.so" is 64-bit instead of 32-bit.' This doesn't happen on my Fire HD 8s running 6.3.0.1.
I tried copying mtk-su, which gives me root access if I run it directly, into /system/xbin and creating a symbolic link to it with 'ln -s mtk-su su'. I was able to get a root prompt in the Fire OS shell by executing /system/xbin/su, but when I tried hiding Link2SD in Magisk Manager so it would (hopefully) open su from /system/xbin, which is at the end of my $PATH . . . nothing. I got the Spinning Wheel Of Death and Link2SD never launched. Apparently it was trying to launch mtk-su (as just 'su') behind the scenes and wasn't able to do so, or was waiting for something else to give it permission, or . . . well who knows.
So here I am. I think if I had an su binary that wasn't just a symlink to 'magisk', and that used the libraries in /system/lib, I could drop it into /system/xbin and Link2SD would fire it up if I hid Magisk from it. Any suggestions?
Thanks in advance.
Click to expand...
Click to collapse
Link2SD doesn't uses the Magisk SU. It's only using SuperSU.
AmznUser444 Dev said:
Link2SD doesn't uses the Magisk SU. It's only using SuperSU.
Click to expand...
Click to collapse
As far as I know I don't have SuperSU installed. I searched through all of the directories in my $PATH and the only 'su' I found was the link I posted in the OP.
NerdFire said:
As far as I know I don't have SuperSU installed. I searched through all of the directories in my $PATH and the only 'su' I found was the link I posted in the OP.
Click to expand...
Click to collapse
No sweat. You can easily flash SuperSu SR5 2.82 from Twrp, and don't do Magisk. The only issue is that you have to enable 'allow root by default' in supersu since it does not work if the apps have to ask.
If the stock SR5 does not work, try the slightly modded version from here: https://forum.xda-developers.com/showpost.php?p=74987123&postcount=2
Pre-unlock SuperSu was the only way to go, and it still works fine, but root access control is nonfunctional.
Post back what worked for you!
bibikalka said:
No sweat. You can easily flash SuperSu SR5 2.82 from Twrp, and don't do Magisk.
Click to expand...
Click to collapse
Huh. For some reason I thought SuperSu had gone the way of high-button shoes and daytime baseball. I'll have to go check it out. Thanks!