195

I have a problem connecting HTC Wildfire A3333 in debugging mode with my Fedora Linux 17. Adb says:

./adb devices
List of devices attached 
????????????    no permissions

my udev rules (first rule for Samsung which works just fine and second for HTC which is not):

SUBSYSTEM=="usb",SYSFS{idVendor}=="04e8",SYMLINK+="android_adb",MODE="0666",GROUP="plugdev" 
SUBSYSTEM=="usb",SYSFS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666",GROUP="plugdev"

For Samsung devices everything's okay:

 ./adb devices
List of devices attached 
00198a9422618e  device

I have been trying all of the answers given in a simmilar thread wthout any luck: Using HTC wildfire for android development

Alex P.
  • 30,437
  • 17
  • 118
  • 169
XorOrNor
  • 8,868
  • 12
  • 48
  • 81
  • I was able to work with HTC Wildfire in fedora 17/18 runing eclipse as a root user. – IsaacCisneros Jan 22 '13 at 22:42
  • 9
    Step 3 from http://developer.android.com/tools/device.html – E-rich Dec 12 '13 at 22:17
  • The solution is to change SYSFS into ATTR. As Michael says in his answer. – minghua Apr 05 '14 at 20:27
  • 2
    There are a lot of **bad answers** here which unwisely suggest running ADB as root with sudo or by making it setuid. That is not how it is intended to be used. A *proper* udev rule will make the device available to adb when run under your user account, *not* as root. – Chris Stratton May 01 '15 at 16:18
  • @Chris Stratton Maybe you could post the correct answer rather than keep posting that every answer here is wrong? This doesn't get things any better... – XorOrNor May 06 '15 at 08:58
  • I had the same problem and re-enabling the option `Media device (MTP)` did the trick. This is somewhat hidden under Settings->Storage and then USB computer connection via the Storage menu. – Daniel Jul 01 '15 at 18:41

20 Answers20

374

I just had this problem myself under Debian Wheezy. I restarted the adb daemon with sudo:

sudo ./adb kill-server
sudo ./adb start-server
sudo ./adb devices

Everything is working :)

pevik
  • 4,523
  • 3
  • 33
  • 44
Leon
  • 12,013
  • 5
  • 36
  • 59
  • 1
    Well it works but it's not very comfortable to do so everytime you want to test your app. – XorOrNor May 08 '13 at 14:45
  • 5
    Giving adb root access by default bothers me, especially since all devices do not need adb to as root. To make things easier you can create a bash script and run that with sudo – Leon May 10 '13 at 12:19
  • 2
    Using `sudo` you're running `adb` as root anyway (with super user privileges)... – XorOrNor May 14 '13 at 11:26
  • 1
    True, but only when you relaunch it – Leon May 14 '13 at 13:43
  • I don't understand your logic. Sudo and SUID effect exactly the same - running binary with super privileges. – XorOrNor May 22 '13 at 11:24
  • 3
    Thanks this pointed me in the right direction. Like to point out that on my system it's sufficient to run start-server as root. I then run adb as normal user, and it shows my Ouya. – Zane Jul 13 '13 at 18:16
  • This worked for me on Ubuntu 11.04 – Will Sheppard Aug 30 '13 at 08:54
  • 1
    Running adb as root from sudo is cumbersome because the IDE (Eclipse) will not know to do it automatically. Not to mention that it is a security risk. Making the USB device writable by the user is the proper solution. – chvor Oct 08 '13 at 09:39
  • This is a good quick solution that works (if run as 'sudo' as described), but it's not permanent. It needs to be re-issued after every reboot. Better, would be the permanent solution by @MichaelWitrant. – Brent Faust Nov 19 '13 at 20:21
  • @Leon what if user is not superuser...any suggestion? – CoDe Feb 14 '14 at 10:01
  • This is absolutely the correct fix for connecting to the Lenovo Yoga 2 tablets on linux. – Brian Ballsun-Stanton Aug 13 '15 at 07:13
  • Generally, YES, it helps... But sometimes you need to do a couple dozen of these... – Yaroslav Voytovych Nov 27 '15 at 14:37
107

The cause of that problem has to do with system permissions (thanks @ IsaacCisneros for this suggestion). Somehow HTC Wildfire (and maybe the others) need something more from the system than Samsung devices. Simple solution is to run Eclipse as a root, but this is not very comfortable with non-sudo Linux systems like Fedora.

I've found another way of achieving the same goal, which seems to be more user friendly and is lesser security hole then running entire IDE with super user privileges. Mind this is still only a workaround of the problem. System root usage should be minimalized only to administrative tasks, and “adb” was designed to work with normal user account without SUID. Despite of the fact that the proper setting of SUID is quite secure, every single permission increase is a potential system security hole.

1.Setting ownership of the adb binary (owner – root, owner group - user_group):

chown root:user_group adb

2.Setting permissions with SUID:

chmod 4550 adb

This should result something similar to this (ls -llh):

-r-sr-x---. 1 root user_name 1.2M Jan 8 11:42 adb

After that you will be able to run adb as a root, event though you'll be using your normal user account. You can run Eclipse as a normal user and your HTC should be discovered properly.

./adb devices 
List of devices attached 
HT0BPPY15230    device
XorOrNor
  • 8,868
  • 12
  • 48
  • 81
  • As a new (happy) fedora user I just thought easy. Believe me there are a lot of "exotic" android devices that require more system permissions than Samsung ones, Thanks for this useful information I also was not comfortable working with eclipse as a root. – IsaacCisneros Jan 24 '13 at 22:46
  • this worked for me as well, using Ubuntu 12.10 and Geeksphone Keon – Aras May 22 '13 at 05:35
  • 5
    I’m sorry, there are no magic permissions involved. I will not believe otherwise unless someone tells me _which_ permission we talk about. – See my answer on how to really debug the problem. (Then you can undo this “insecure” suid hack.) – Robert Siemer Jun 03 '13 at 17:58
  • @RobertSiemer correct. Anyone looking for a solution should try Leon's answer (kill the adb server) – Brent Faust Nov 19 '13 at 00:22
  • This is not the right answer. adb already runs, as you can see in the output: "List of devices attached...". There are correct answers given below, the easiest of which is to kill and restart the adb server on the remote device given by Leon. Stephan's answer also works (and I've shown how to make it permanent in my answer). – Brent Faust Dec 03 '13 at 04:32
  • I also had to run: ``# adb usb`` to resstart the adbd daemon listining on usb. – danbruegge Feb 12 '14 at 08:24
  • Worked for me. I aslo needs to adb kill-server && adb start-server – wukong Mar 27 '15 at 08:06
  • 4
    This is incorrect. No device requires ADB to run as root. Rather, the udev rule is not correct. – Chris Stratton May 01 '15 at 04:55
  • additionally, I had to remove adb logs after killing adb server and before starting it: `sudo rm /tmp/adb.*` – eeqk Nov 03 '20 at 21:04
99

I have a similar problem:

$ adb devices
List of devices attached 
4df15d6e02a55f15    device
????????????    no permissions

Investigation

If I run lsusb, I can see which devices I have connected, and where:

$ lsusb
...
Bus 002 Device 050: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone ...
Bus 002 Device 049: ID 18d1:4e42 Google Inc.

This is showing my Samsung Galaxy S3 and my Nexus 7 (2012) connected.

Checking the permissions on those:

$ ls -l /dev/bus/usb/002/{049,050}
crw-rw-r--  1 root root    189, 176 Oct 10 10:09 /dev/bus/usb/002/049
crw-rw-r--+ 1 root plugdev 189, 177 Oct 10 10:12 /dev/bus/usb/002/050

Wait. What? Where did that "plugdev" group come from?

$ cd /lib/udev/rules.d/
$ grep -R "6860.*plugdev" .
./40-libgphoto2-2.rules:ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="6860", \
  ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", \
  ENV{ID_MEDIA_PLAYER}="1", MODE="0664", GROUP="plugdev"
./40-libgphoto2-2.rules:ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", \
  ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", \
  ENV{ID_MEDIA_PLAYER}="1", MODE="0664", GROUP="plugdev"

(I've wrapped those lines)

Note the GROUP="plugdev" lines. Also note that this doesn't work for the other device ID:

$ grep -Ri "4e42.*plugdev" .

(nothing is returned)

Fixing it

OK. So what's the fix?

Add a rule

Create a file /etc/udev/rules.d/99-adb.rules containing the following line:

ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e42", ENV{ID_GPHOTO2}="1",
  ENV{GPHOTO2_DRIVER}="proprietary", ENV{ID_MEDIA_PLAYER}="1",
  MODE="0664", GROUP="plugdev"

This should be a single line, I've wrapped it here for readability

Restart udev

$ sudo udevadm control --reload-rules
$ sudo service udev restart

That's it

Unplug/replug your device.

Try it

$ adb devices
List of devices attached 
4df15d6e02a55f15    device
015d2109ce67fa0c    device
Roger Lipscombe
  • 89,048
  • 55
  • 235
  • 380
  • 1
    Thanks for posting this, as it helped me even though I had to do something slightly different: I just had to change the permissions on the bus file to let everyone have access, restart the adb and then authorise my computer on the phone. Sadly I have to re-apply the permissions every time I disconnected the phone, but so far so good. – DiscoStu Mar 27 '14 at 18:22
  • 1
    Bravo!! it just worked.. Thank you so much, +1 for the post. – yuva Aug 29 '14 at 05:17
  • Make sure for the hex digits 'a' to 'f', use lower-case letters instead of the upper one. – Carson Ip Nov 14 '14 at 08:00
  • I'm mystified by the inclusion of `GPHOTO2` in a script about `adb`. – Faheem Mitha May 05 '15 at 01:56
  • Copy-paste from the working device. I don't know if it's _necessary_, but then you find yourself asking "why is this Android device different from the others?" – Roger Lipscombe May 05 '15 at 09:18
  • 1
    This is by far the best answer. – hgoebl Aug 10 '15 at 13:19
  • @FaheemMitha My guess is that since (modern) Android devices can present themselves as a 'PTP' or an 'MTP' device (photo or media) device. Old Android systems required unmounting the sdcard so it could present as a USB block device. Now the MTP protocol allows the device to keep the filesystem mounted and accessible by the device while connected. – dsh Oct 21 '15 at 14:20
37

You udev rule seems wrong. I used this and it worked:

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"

(ATTR instead of SYSFS)

Michaël Witrant
  • 7,525
  • 40
  • 44
  • 5
    This is the real solution. – Paolo Casciello Oct 07 '13 at 15:38
  • 1
    This works for my device too. I also added a more specific check for the idProduct of the device along with the idVendor check. You can see all the files that can be checked by running lsusb -v. Note that MODE="0666" is not required if your user is part of the "plugdev" group. MODE="0664" is enough in that case (and results in a more secure setup). – chvor Oct 08 '13 at 09:44
  • 4
    +1 because this is the official solution suggested by google: http://developer.android.com/tools/device.html – eang Nov 11 '13 at 09:40
  • 1
    I also needed to add OWNER="myuser" to this line in the UDEV rule file to resolve this for me. – alpartis Jan 15 '14 at 01:45
  • http://askubuntu.com/a/213907/112263 – CrandellWS Nov 02 '16 at 18:39
32

Changing the USB Mode from phone did the trick for me. (I set it to File Transfer)

NuttLoose
  • 665
  • 7
  • 11
26

under ubuntu 12.04, eclipse juno. I face the same issue. This what I found on Yi Yu Blog

The solution is same as same as Leon

sudo -s
adb kill-server
adb start-server
adb devices
Chan
  • 914
  • 9
  • 25
  • 1
    Good link to an older source (credits are always nice to give). Looks Like Jan had applied the permanent solution on the blog you linked but that was still not solving. I had the same problem with Samsung device however and that fix works for it. – a1an Mar 24 '13 at 13:43
  • Works! Adb server would ask the device for permission – Bùi Thanh Hải Aug 29 '14 at 15:59
  • 1
    No. This is not the correct answer. It is bad practice - adb is not intended to be run as root. – Chris Stratton May 01 '15 at 04:57
26

Stephan's answer works (using sudo adb kill-server), but it is temporary. It must be re-issued after every reboot.

For a permanent solution, the udev config must be modified:

Witrant's answer is the right idea (copied from the official Android documentation). But it's just a template. If that doesn't work for your device, you need to fill in the correct device ID for your device(s).

lsusb

Bus 001 Device 002: ID 05c6:9025 Qualcomm, Inc.
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
...

Find your android device in the list.

Then use the first half of the ID (4 digits) for the idVendor (the last half is the idProduct, but it is not necessary to get adb working).

sudo vi /etc/udev/rules.d/51-android.rules and add one rule for each unique idVendor:

SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", MODE="0666", GROUP="plugdev"

It's that simple. You don't need all those other fields given in some of the answers. Save the file.

Then reboot. The change is permanent. (Roger shows a way to restart udev, if you don't want to reboot).

Brent Faust
  • 9,103
  • 6
  • 53
  • 57
22

...the OP’s own answer is wrong in so far, that there are no “special system permissions”. – The “no permission” problem boils down to ... no permissions.

Unfortunately it is not easy to debug, because adb makes it a secret which device it tries to access! On Linux, it tries to open the “USB serial converter” device of the phone, which is e.g. /dev/bus/usb/001/115 (your bus number and device address will vary). This is sometimes linked and used from /dev/android_adb.

lsusb will help to find bus number and device address. Beware that the device address will change for sure if you re-plug, as might the bus number if the port gets confused about which speed to use (e.g. one physical port ends up on one logical bus or another).

An lsusb-line looks similar to this: Bus 001 Device 115: ID 4321:fedc bla bla bla

lsusb -v might help you to find the device if the “bla bla bla” is not hint enough (sometimes it does neither contain the manufacturer, nor the model of the phone).

Once you know the device, check with your own eyes that ls -a /dev/bus/usb/001/115 is really accessible for the user in question! Then check that it works with chmod and fix your udev setup.

PS1: /dev/android_adb can only point to one device, so make sure it does what you want.

PS2: Unrelated to this question, but less well known: adb has a fixed list of vendor ids it goes through. This list can be extended from ~/.android/adb_usb.ini, which should contain 0x4321 (if we follow my example lsusb line from above). – Not needed here, as you don’t even get a “no permissions” if the vendor id is not known.

Robert Siemer
  • 32,405
  • 11
  • 84
  • 94
  • 1
    Just a note, if you don't have lsusb installed. You can install it by doing sudo apt-get install usbutils locate – Stephan Branczyk Jun 15 '13 at 23:31
  • Do you have a hint what to do if the device list is empty? I think I have checked everything, including permissions to the USB post in `/dev/bus/usb/...`: http://android.stackexchange.com/q/47938/13266 – krlmlr Jun 25 '13 at 13:10
  • This worked for me on Linux Mint. I found that changing the permissions of /dev/bus/usb/002/013 to 777 allowed me to see my device in adb devices. Thanks. – MungoRae Nov 17 '13 at 16:53
  • @RobertSiemer can we add multiple devices in 51-android.rules file – Akshay Mukadam Nov 02 '14 at 09:36
  • @james Yes. I could. – But why are you asking me? And don’t forget to upvote this and my other answers. :-P – Robert Siemer Nov 02 '14 at 12:16
8

I'll prepend this postscript here at the top so it won't get lost in my earlier explanation.

I can reliably produce and resolve the no-permissions problem by simply changing the USB connection type from Camera (PTP) to Media device (MTP). The camera mode allows debugging; the media mode causes the no-permissions response in ADB.

The reasoning seems pretty evident after reflecting on that for a moment. Unsecured content on the device would be made accessible by the debugger in media server mode.

===========

The device is unpermissioned until you accept the RSA encryption warning on the debugged device. At some point after connecting, the device will ask to accept the debugging connection. It's a minimal security protocol that ensures you can access the device beyond the initial swipe lock. Developer mode needs to be enabled, I believe.

The "no permissions" flag is actually a good first indicator that adb recognizes the device as a valid debugging target. Notice that it doesn't list your other USB devices.

Details at the following and related pages.

http://developer.android.com/tools/device.html

MikeW
  • 89
  • 1
  • 4
8

Same problem with Pipo S1S after upgrading to 4.2.2 stock rom Jun 4.

$ adb devices
List of devices attached  
????????????    no permissions

All of the above suggestions, while valid to get your usb device recognised, do not solve the problem for me. (Android Debug Bridge version 1.0.31 running on Mint 15.)

Updating android sdk tools etc resets ~/.android/adb_usb.ini.

To recognise Pipo VendorID 0x2207 do these steps

Add to line /etc/udev/rules.d/51-android.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="0x2207", MODE="0666", GROUP="plugdev"

Add line to ~/.android/adb_usb.ini: 

0x2207

Then remove the adbkey files

rm -f ~/.android/adbkey ~/.android/adbkey.pub

and reconnect your device to rebuild the key files with a correct adb connection. Some devices will ask to re-authorize.

sudo adb kill-server
sudo adb start-server   
adb devices
pevik
  • 4,523
  • 3
  • 33
  • 44
Dorian Carlill
  • 81
  • 1
  • 2
4

Had the same issue. It was a problem with udev rules. Tried a few of the rules mentioned above but didnot fix the issue. Found a set of rules here, https://github.com/M0Rf30/android-udev-rules. Followed the guide there and, voila, fixed.

Anish Unnikrishnan
  • 171
  • 1
  • 8
3

I encountered the same problem today.

I followed the official instructions, but I didn't noticed that I SHOULD run command
"chmod a+r /etc/udev/rules.d/51-android.rules"

After I set this file to world readable and re-plug my usb cable，the status became unauthorized. Then just grant the permission and everything goes fine.

VicX
  • 721
  • 8
  • 13
2

I agree with Robert Siemer and Michaël Witrant. If it's not working, try to debug with strace

strace adb devices

In my case it helps to kill all instances and remove socket file /tmp/ADB_PORT (the default is /tmp/5037).

pevik
  • 4,523
  • 3
  • 33
  • 44
1

Another possible source of this issue is USB tethering. If you have used USB tethering, turn it off, then unplug the device from USB, plug it back in, then do 

adb kill-server
adb devices

That did the trick in my case (Ubuntu 12.04, Nexus S, SDK in home dir, never needed root to get it running). Depending on your device, you may need to run adb devices as root, though.

user149408
  • 5,385
  • 4
  • 33
  • 69
  • Having killed the server process, it won't be able to detect any devices. You need to restart the service, in the order mentioned in the [selected answer](http://stackoverflow.com/a/15043526/1105203). Needing root privileges on your server to bridge the SDK and phone via `adb` is unrelated to the device's configuration or model. – Alastair Mar 07 '14 at 20:35
  • `adb devices` will start the service if it is not running. The preceding `adb kill-server` is needed if something got stuck in the adb service – the sequence of commands will effectively kill any running adb services and start a new instance. As a matter of fact, the Geeksphone One required a customized ADB version, which would only work as root (http://forum.geeksphone.com/index.php?topic=359.0). – user149408 Mar 09 '14 at 22:05
  • Oh yeah...I forgot about `* daemon not running. starting it now on port 5037 *`! I haven't had the good fortune of trying any GeeksPhone phones yet but except from that modified `adb` binary, I don't think the root-requirements apply. – Alastair Mar 12 '14 at 05:33
  • I switched off wifi and unpaired all bluetooths, removed usb again plugged and it worked – Bhupinder Jun 15 '15 at 08:23
1

Try "android update adb" command. It helps me with samsung galaxy gear.

Alex Kutsko
  • 1,129
  • 11
  • 9
1

The output of ls -al /usr/bin/adb should show that it is owned by user root and group root. You can use Linux ACL (Access Control Lists) to give your local user permissions for adb as follows:

setfacl -m "u:userName:rwx" /usr/bin/adb

This is preferable to setting the SUID bit on /usr/bin/adb and also limits the users who can use adb to userName and root.

Jun_in_Jeju
  • 11
  • 1
  • 2
0

The answer is weaved amongst the various posts here, I'll so my best, but it looks like a really simple and obvious reason.

1) is that there usually is a "user" variable in the udev rule some thing like USER="your_user" probably right after the GROUP="plugdev"

2) You need to use the correct SYSFS{idVendor}==”####″ and SYSFS{idProduct}=="####" values for your device/s. If you have devices from more than one manufacture, say like one from Samsung and one from HTC, then you need to have an entry(rule) for each vendor, not an entry for each device but for each different vendor you will use, so you need an entry for HTC and Samsung. It looks like you have your entry for Samsung now you need another. Remember the USER="your_user". Use 'lsusb' like Robert Seimer suggests to find the idVendor and idProduct, they are usually some numbers and letters in this format X#X#:#X#X I think the first one is the idVendor and the second idProduct but your going to need to do this for each brand of phone/tablet you have.

3) I havent figured out how 51-adb.rules and 99-adb.rules are different or why.

4) maybe try adding "plugdev" group to your user with "usermod -a -G plugdev your_user", Try that at your own risk, though I don't thinks it anyriskier than launching a gui as root but I believe if necessary you should at least use "gksudo eclipse" instead.

I hope that helped clearify some things, the udev rules syntax is a bit of a mystery to me aswell, but from what I hear it can be different for different systems so try some things out, one ate a time, and note what change works.

Overloaded_Operator
  • 657
  • 6
  • 9
  • 51-adb.rules is read before 99-adb.rules. The number is fairly arbitrary, but determines the order the files area read by udev on boot. – Brent Faust Nov 19 '13 at 20:22
  • Now USER="your_user" have to be OWNER="your_user" instead. example for google: cat /etc/udev/rules.d/61_nexus_5.rules SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev", OWNER="jenkins" – Filip Stefanov Mar 27 '17 at 10:13
0

  1. Close running adb, could be closing running android-studio.

  2. list devices,

/usr/local/android-studio/sdk/platform-tools/adb devices

prayagupa
  • 30,204
  • 14
  • 155
  • 192
-1

On THL W100 running the device as root (as described above) worked only together with tethering enabled (I used AirDroid for that).

mary jane
  • 532
  • 6
  • 19
-1

I had the same situation where three devices connected to one same host but only one had 'no permissions' others were online.

Adding SUID or SGID on adb was another issue for me. Devices seen offline every time adb restarts - until you acknowledge on the devices every time.

I solved this 'no permissions' issue by adding 'o+w' permission for a device file.

chmod o+w /dev/bus/usb/00n/xxx

Stephan Kristyn
  • 15,015
  • 14
  • 88
  • 147
Kenichi Takemura
  • 69
  • 3