This question already has an answer here:
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
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.
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
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.
...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 withchmod
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.
You udev rule seems wrong. I used this and it worked:
(
ATTR
instead ofSYSFS
)I just had this problem myself under Debian Wheezy. I restarted the adb daemon with sudo:
Everything is working :)