I recently did a factory reset of my android phone. Prior to the reset, I was able to install applications through adb install. The phone was not rooted.
After the factory reset, I mostly get "Operation not permitted" for nearly every command in adb shell (including ones that don't exist):
$ install
install: permission denied
$ push
push: permission denied
$ remount
remount: permission denied
$ su
su: permission denied
$ kmmsaldfmaldskfmlasdf
kmmsaldfmaldskfmlasdf: permission denied
$
Most of the PATH is unreadable to me (except for /system/bin and /system/xbin):
$ echo $PATH
/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
$ ls /sbin
opendir failed, Permission denied
$ ls /vendor/bin
/vendor/bin: No such file or directory
$ ls /system/sbin/
/system/sbin/: No such file or directory
If I run adb root:
$ adb root
adbd cannot run as root in production builds
From my search (which has already robbed me of way more time than necessary), some pointers are to default.prop:
$ cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=1
$
But I have no write access to default.prop:
$ ls -l default.prop
-rw-r--r-- root root 118 1969-12-31 19:00 default.prop
$
I also seem unable to remount. I have been able to use adb successfully on the non-rooted device, why so much grief now? Has anyone come across this problem? My own phone is virtually unusable to me, and of course I am unable to do any development.
Trying to remount as rw:
$ mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/stl9 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=cp437 0 0
/dev/stl10 /cache rfs rw,nosuid,nodev,relatime,vfat,llw,gid/uid/rwx,iocharset=cp437 0 0
/dev/stl6 /mnt/.lfs j4fs rw,relatime 0 0
/dev/stl11 /data rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=cp437 0 0
$ mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /
mount: Operation not permitted
My phone is a Samsung Galaxy Y, which could matter
You need to issue commands like install from the PC command line:
C:\> adb install ...
instead of from within the adb shell. If that doesn't work, you may need to run
adb remount
and/or reboot your phone and/or reinstall the phone driver. See this thread for more info.
I've found that the path in an adb shell session can have all sorts of non-existent directories on it. I don't know why that is, but it normally doesn't screw up anything.
Assuming that you didn't put a new version of Android on your phone, my guess is that your phone is no longer in developer mode.
Go to Settings. Scroll down until you see the System heading. Under it, you should see several options. If Developer is not one of them, click on About phone, then scroll down to Build number. Click on Build number 7 times. That should bring back Developer mode.
Try executing these commands from in recovery, most recent recoveries are debuggable=1
other then that decompile the kernel and change ro.debuggable=0 to 1 and that will allow you to remount with adb and allow adb to run as root!
I might have found a solution for you
Recently i updated my (rooted) LGP500 from Froyo (android 2.2.1) to Gingerbeard (android 2.3.3). After that i found myself in a situation, quite similar to yours (the same, to be honest). I lost my SU credentials, and desperately tried to find a solution to that problem. I was so desperate - i even tried famous Android 4.2 method of enabling developer settings, tapping my poor device like a madman for quite some time.
So... i've had exactly the same issue. While surfing the web i found out that the problem was actually in the Gingerbeard build, and stumbled upon some interesting solutions.
And, after all the effort - it took me quite some time to figure out which way is the best - i (finally) had my 2.3.3 device rooted.
Note that i only share these things in educational purposes only. No offence taken if you brick your device by accident.
Before proceeding check if:
You have properly installed ADB drivers (if not - will show an error
with the following text: "could not find online device, please enable
USB debugging!"; solution - install or reinstall ADB drivers. Mind
that you have to install drivers with your device connected, BUT "USB
debugging" disabled.
You have "USB debugging" and "Allow mock locations" checked.
It is highly advisable to have a backup to prevent any data loss.
(At least export your contacts to .vcf file)
If everything is OK:
Install UnlockRoot (you can find Unlock_Root_2.3.0.exe here) and execute it.
Run "root" (You can actually ignore everything but the "root" button). Choose your device in the pop-up menu.
Reboot your device (to finish the installation of the SU binary - you will be prompted in the app if you wish to reboot, but are free to do it yourself through adb shell )
And voila! your device is rooted, just like that.
You should install the SuperSU app from Google Play. That is the only super-user app which enabled root functionality correctly on my device (Galaxy S4).
After that do adb shell and su. If you want to pull a file from /data directory, you will need to change permissions of that file (using chmod). Then it should work!
I had this problem endlessly on my galaxy S3
When i built my android kitchen i found a way around this
Root the device if you need elavated permissions
Unpack build the kernel for your device
in the default.prop change these values to the corresponding
ro.secure=0
ro.debuggable=1
Compile/repack and flash
Enable USB debugging
Your user capabilities are being stripped somewhere. Look at the /proc/<shell process>/status to see the capability mask.
You could try SUInstaller.
http://theroot.ninja/apks/SUInstaller.apk
Basically sets up su on your phone. This MAY work,from memory i used one click androroot to root samsung y.
If this fails,try booting into recovery and flashing supersu, can try samsung galaxy method,or base yours on it,
http://www.android.gs/root-samsung-galaxy-s3-with-cwm-recovery-and-supersu/
Goodluck.
Related
How to know which Emulator image will contain su?
I can see that often it only contains su or google play
Run adb root and you get a root shell ... otherwise su needs to be manually installed.
However, when already having a root shell available, installing it isn't much of a problem.
All images are rooted, but SDK apps requesting escalation of privileges do rely upon su.
This question here generally duplicates: How to get root access on Android emulator?
adb shell scripting must:
start the emulator
run adb root
run adb shell
remount system partition
adb push the su binary
chmod to set permissions
exit
Or to answer the question:
start the emulator
and check if the file exists, eg. with adb shell stat /usr/bin/su
Where stat gives this response, when it's not installed:
stat: '/usr/bin/su': No such file or directory
One could even loop all Android images installed in $ANDROID_SDK_HOME...
there's no "one click" solution, but adb can be fully automated with Bash or Batch. And one wouldn't even have to run the emulator, but can mount QCOW2 as a nbd network block device.
I want to set the SELinux (Security Enhanced Linux) mode to Permissive or (0) on android 4.4.4 (and above if possible). I use the following command: setenforce 0, setenforce permissive and setenforce Permissive under root (my device is rooted). But the output of getenforce is always Enforcing. Now I am exhausted with this problem.
Can any one give me a solution? Thanks in advance.
Depending on how your device was rooted and what Android ROM your running will determine how you can disable it. The first thing to try is:
adb shell su 0 setenforce 0
This is NOT the same as:
adb shell setenforce 0
The execute on su causes a domain transition from shell (which cannot setenforce) into the su domain (which can call setenforce). For instance, run:
$ adb shell id -Z
context=u:r:shell:s0
compared to:
$ adb shell su 0 id -Z
context=u:r:su:s0
This may fail for three reasons:
You do not have the su executable
The su executable has the wrong label
The su domain rules were not compiled into the bootimage
To correct issue 2, you can (assuming adb is root):
adb remount
adb shell chcon /system/xbin/su u:object_r:su_exec:s0
This might fail, which will likely indicate issue 3. To fix issue 3, you need to recompile a boot.img that contains the su policy files. If you're compiling AOSP, just lunch a userdebug or eng variant of your device.
Another approach, would be to remove the functionality from init.c, and like issue 3, requires a recompile of the boot.img. Go into system/core/init/init.c (or .cpp) and remove all calls to security_setenforce().
Additionally, XDA has an application that may help automate this process and make it easier, however, I cannot speak to the quality of the application:
http://www.xda-developers.com/easily-change-your-android-selinux-mode/
Apparently Google has removed the CONFIG_SECURITY_SELINUX_DEVELOP kernel flag from many of their Stock kernels. Thus the standard trick mentioned by William (below) probably doesn't work. An example of these devices is the Samsung Note 4 (SM-N910F) running AOS 4.4.4.
The link above states:
CONFIG_SECURITY_SELINUX_DEVELOP aka global permissive mode, is useful for
when you are first developing device-specific policy for a board (add
'androidboot.selinux=permissive' to BOARD_KERNEL_CMDLINE). It also
permits transient setenforce 0 in -userdebug or -eng builds, which can
be helpful for developers.
If the bootloader is locked, then you can't modify the kernel cmdline
"Also, the code in the init program for processing the
androidboot.selinux= option is only compiled in -userdebug and -eng builds, so even aside from bootloader locking, you cannot use
androidboot.selinux=permissive on a -user build."
The way to check what build type you have is:
$ getprop ro.build.type
user
MUST BE ROOTED! Not sure if this works on KitKat (it should) but I use this on my Nexus 6. Run following in terminal or ADB Shell:
su
mount -o remount,rw /system
mkdir /system/su.d
echo "#!/system/bin/sh" > /system/su.d/permissive.sh
echo "echo 0 > /sys/fs/selinux/enforce" >> /system/su.d/permissive.sh
chmod 755 /system/su.d/permissive.sh
And check it after reboot by this:
su
/system/bin/getenforce
I have written the following shell script:
alias mount='/system/xbin/busybox mount'
set -e
set -x
MNT=sda1
function mkdir_ext() {
if [ ! -d $1 ]; then
mkdir -p $1
fi
chown $2 $1
chmod $3 $1
}
mkdir_ext /storage/emulated/$MNT root:media_rw 777
mount -t ext4 /dev/block/$MNT /storage/emulated/$MNT
mkdir_ext /data/media/$MNT root:media_rw 777
sdcard -u 1023 -g 1023 /storage/emulated/$MNT /data/media/$MNT
After executing the commands above, mount reports:
root#NEO-X8:/sdcard # mount|grep sda
/dev/block/sda1 /storage/emulated/sda1 ext4 rw,seclabel,relatime,data=ordered 0 0
/dev/fuse /data/media/sda1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
I am working via ssh, remotely, using rooted ssh/sftp daemon, and while logged in as root, I can list the files in /storage/emulated/sda1.
From what I understand, android is case-insensitive in regards to filesystems by design, so the filesystem has to be fused.
The problem is, I see just an empty directory in /data/media/sda1. Even stranger is that, if I navigate to /storage/emulated/sda1 from the device as root with bash shell X, I also see an empty directory.
I have tried different other apps and I've tried to also use sdcard_rw instead of media_rw (with the uid / gid 1015 instead of 1023), nothing works.
How to get ext4 to work for all apps on a rooted Minix NEO X8-H? Using anything but ext4 is not an option, the 4TB drive already contains important data. As a side note, sda1 is just a small 1GB partition.
I will assume that your device is rooted from what you have done so far so will not go into that. Though I cannot be certain this is your issue I shall explain how I solved a similar problem.
Resent versions of android with the intent on improving device security are now using the (somewhat half arsed) feature of making mounts performed by most processes not visible to other processes. Working around this is frustratingly device specific, however it appears the Minix NEO X8-H is using a "vanilla" style source build of android. Therefore you have a good chance of using StickMount in order to mount the USB stick, it should enable the global mounting of USB devices running any file-system supported by your ROM (which should include ext4 given you have already mounted it before).
I have not tested this personally on your device so cannot guarantee it will work but have had success with a number of other android devices so this is certainly worth a shot.
I use mkfs -t ext4 /dev/sdf2 format SDcard and insert into samsung s4 anrdoid phone.
adb shell
su
mount /dev/block/mmcblk1p2 /root
I cant't mount this SDcard, I have googled it but no solution.
The last, I found this can succeed :)))
mk2fs -t ext4 /dev/sdf2
and ...
I rooted my unlocked Galaxy S3 (SGH-T999)
Now, I'm trying to run adb root from Windows Command Prompt, however, I'm getting adbd cannot run as root in production builds error. So, the very first thing I checked was whether my phone was really rooted?
So I tried the following:
Open Command prompt
$adb devices // lists my device
$adb shell //goes to shell
$su // opens a 'SuperSu' prompt on my phone and I 'Grant' permission
# // Before following the rooting instructions, I was getting 'no su command found' in the previous step. So, I believe my phone is ROOTED. **Correct me if I'm wrong.**
However, when I do adb root, I get adbd cannot run as root in production builds error.
So, I thought, I might have to do some additional stuff beyond what I did above. I tried all the solutions in the following SO questions:
Launch a script as root through ADB
adb remount permission denied, but able to access super user in shell -- android
Unable to run 'adb root' on a rooted Android phone
None of the above worked for me. All they do is give the ROOT access INSIDE of SHELL. I want adb root to work so that I can execute various adb commands WITHOUT going into shell.
By design adb root command works in development builds only (i.e. eng and userdebug which have ro.debuggable=1 by default). So to enable the adb root command on your otherwise rooted device just add the ro.debuggable=1 line to one of the following files:
/system/build.prop
/system/default.prop
/data/local.prop
If you want adb shell to start as root by default - then add ro.secure=0 as well.
Alternatively you could use modified adbd binary (which does not check for ro.debuggable)
From https://android.googlesource.com/platform/system/core/+/master/adb/daemon/main.cpp
#if defined(ALLOW_ADBD_ROOT)
// The properties that affect `adb root` and `adb unroot` are ro.secure and
// ro.debuggable. In this context the names don't make the expected behavior
// particularly obvious.
//
// ro.debuggable:
// Allowed to become root, but not necessarily the default. Set to 1 on
// eng and userdebug builds.
//
// ro.secure:
// Drop privileges by default. Set to 1 on userdebug and user builds.
In some developer-friendly ROMs you could just enable Root Access in Settings > Developer option > Root access. After that adb root becomes available. Unfortunately it does not work for most stock ROMs on the market.
I ran into this issue when trying to root the emulator, I found out it was because I was running the Nexus 5x emulator which had Google Play on it. Created a different emulator that didn't have google play and adb root will root the device for you. Hope this helps someone.
I use for enter su mode in abd shell
adb shell "su"
I have a rooted Samsung Galaxy Trend Plus (GT-S7580).
Running 'adb root' gives me the same 'adbd cannot run as root in production builds' error.
For devices that have Developer Options -> Root access, choose "ADB only" to provide adb root access to the device (as suggested by NgaNguyenDuy).
Then try to run the command as per the solution at Launch a script as root through ADB.
In my case, I just wanted to run the 'netcfg rndis0 dhcp' command, and I did it this way:
adb shell "su -c netcfg rndis0 dhcp"
Please check whether you are making any mistakes while running it this way.
If it still does not work, check whether you rooted the device correctly.
If still no luck, try installing a custom ROM such as Cyanogen Mod in order for 'adb root' to work.
You need to replace the adbd binary in the boot.img/sbin/ folder to one that is su capable. You will also have to make some default.prop edits too.
Samsung seems to make this more difficult than other vendors. I have some adbd binaries you can try but it will require the knowledge of de-compiling and re-compiling the boot.img with the new binary. Also, if you have a locked bootloader... this is not gonna happen.
Also Chainfire has an app that will grant adbd root permission in the play store: https://play.google.com/store/apps/details?id=eu.chainfire.adbd&hl=en
Lastly, if you are trying to write a windows script with SU permissions you can do this buy using the following command style... However, you will at least need to grant (on the phone) SU permissions the frist time its ran...
adb shell "su -c ls" <-list working directory with su rights.
adb shell "su -c echo anytext > /data/test.file"
These are just some examples. If you state specifically what you are trying to accomplish I may be able to give more specific advice
-scosler
adbd has a compilation flag/option to enable root access: ALLOW_ADBD_ROOT=1.
Up to Android 9: If adbd on your device is compiled without that flag, it will always drop privileges when starting up and thus "adb root" will not help at all.
I had to patch the calls to setuid(), setgid(), setgroups() and the capability drops out of the binary myself to get a permanently rooted adbd on my ebook reader.
With Android 10 this changed; when the phone/tablet is unlocked (ro.boot.verifiedbootstate == "orange"), then adb root mode is possible in any case.
If you really need to have ADB running as root, the quickest and easiest way is to install Android Custom ROMs and the most popular is CyanogenMod for it has the Root Access options in developer options menu where you can choose to give root access to apps and ADB. I used CM before but since it wasn't developed anymore, I tried looking for some solutions out there. Although CyanogenMod is still a good alternative because it does not have bloatware.
One alternative I found out from a friend is using adbd insecure app which you could try from here: https://forum.xda-developers.com/showthread.php?t=1687590. In my case, it works perferct with an Android custom kernel, but not with the Android stock ROM (vanilla android only). You may try other alternatives too like modifying boot.img of the Android ROM.
in my case, ( device is rooted )
linux$ adb shell # in linux shell
mobile$ su root #=> notice the $ will become #
mobile# whoami #=> root
if you installed "adb root" module in Magisk, you still have to manually switch to root by su root, otherwise, it just LOOKS LIKE you are root, but actually you are NOT root.
I have a Samsung Galaxy Tab S2 running Android 7.0.
Here's how I rooted it today:
Root the device using Odin
Read Alex P.'s answer in this thread regarding editing system\build.prop file.
download onto your tablet: v1.3.9 System Tools Android: All-In-One toolbox
run the app; under "System Utilities" confirm your Odin root worked using "Root Check"
in the same app goto "Root Manager" and use the "Build.prop editor" to effect the changes in the system\build.prop (as specified by Alex P.).
Final Confirmation:
C:\Android\sdk\platform-tools>adb shell
gts28vewifi:/ $ whoami
shell
gts28vewifi:/ $ su
gts28vewifi:/ # su root
gts28vewifi:/ # whoami
root
Upvote Alex P.'s answer.
Further info
and here
and here too
Root Access in Windows Command: adb shell su
Root Access in MacOS Command: ./adb shell su
This is a recurrent question, and it seems it has several reasons. I cannot discover mine, even after googling. Several people had answered this question, though.
The problem is that when I try to run an android project with Eclipse and ADB, I get:
Failed to get the adb version: Cannot run program "/extraHD/android/android-sdk-linux/platform-tools/adb":
error=13, Permission denied from '/extraHD/android/android-sdk-linux/platform-tools/adb'
- exists=true
Some data:
1) /extraHD is my second HD, 180GB free, where I have full permissions
2) adb executable has full permission 777
3) If, after 'cd /extraHD/android/android-sdk-linux/platform-tools', I run any of these (no adb process running):
./adb
./adb shell
./adb start-server
./adb kill-server
./adb shell kill you
./adb root
./adb remount
I get the very same answer:
bash: ./adb: Permission denied
And same answer when executing as root! I can create/delete files in that directory, even as a normal user...
Same problem after reinstalling ADB, both through Eclipse and zip file.
Rebooting didn't work either.
I get the same problem with /extraHD/android/android-sdk-linux//tools/emulator.
Tried fsck, reinstalled Eclipse, reinstalled Tools and Platform-tools (adb in particular), reinstalled the APIs. Same thing.
Clues??
I had a similar problem and I solved it by doing the following (mounting the sdk partition at boot time and changing permissions in fstab in order to allow writing in Windows NTFS partition):
Open a terminal, you can use Ctrl+Alt+t
Use 'blkid' to list the block devices and print the universally unique identifiers (UUID)
sudo blkid
Locate the line with the label of your SDK partition and copy the UUID value:
/dev/sXX: LABEL="secondHD" UUID="copy_this" TYPE="ntfs"
Add a new line at the end of the fstab file so the partition will be mounted during boot:
sudo gedit /etc/fstab
Remember to customize the "your.." values, the order it's important, fields on each line are separated by tabs or space; type man fstab for further information). Save and exit.
UUID="yourValueCopied" "yourPartitionPath&Name" ntfs users,uid="YourGroup",gid="YourUserGroup",umask=0022,exec,permissions,auto 0 2
Restart the computer and try another time adb :)
Seems that It's a ntfs partition issue:
https://askubuntu.com/questions/207180/changing-permissions-in-fstab-in-order-to-allow-writing-in-windows-ntfs-partitio
A very good explanation of fstab-permission-masks:
http://www.omaroid.com/fstab-permission-masks-explained/