1

avrdude is a simple tool that allows downloading of a program to a target microcontroller. For completeness, the command I am trying to issue is:

avrdude -p atmega328p -c usbtiny -P usb -v -U -flash:w:program.hex

Every time I issue this command I am subjected the error 'Operation not permitted" and am required to sudo avrdude .. in order to get it to work. I found it strange it was necessary to do this, so I dove into the problem a bit more.

The programmer I am using mounts itself at /dev/ttyUSB0 and is part of the dialout group. Further, this device has permissions such that any user in the dialout group shall be able to write to the device, which is what the command above does.

crw-rw----  1 root dialout   188,   0 Jul 15 02:04 ttyUSB0

Despite rootowning the device, simply adding myself to the dialout group seemed to be sufficient to allow myself to use the device. After doing this, I still was met with the error "Operation not permitted".

I thought, then, that perhaps the avrdude program itself was the problem. After finding the binary in /usr/bin it was clear that this was not an issue given the permissions of the file.

-rwxr-xr-x 1 root root 413888 Oct 21 2013 avrdude

tl;dr I am part of the appropriate group and the files have permissions that should allow me to use them, yet I am still unable to without first elevating myself.

1
  • Changing the owner or the group would do—you'd use the group if you want to potentially have multiple users access it (by adding multiple users to the group).
    – derobert
    Jul 17 '15 at 6:08
2

Low-level control of USB devices is done via /dev/bus/usb, and you need to set the right permissions on the device there. The way to do that is with a udev rule:

Create a file (such as /etc/udev/rules.d/52_local-usbtiny.rules) with:

SUBSYSTEM=="usb", ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", MODE="664", GROUP="plugdev"

That sets the group to plugdev; you could use USER="your-user-name" instead to set the owner.

Then reload udev (e.g., service udev force-reload or systemctl reload udev). Next time you unplug/replug the programmer, the new permissions should take effect.

4
  • I was just reading about udev in general. It seems that the numbers in the rule names are used to order the execution of rules. Why did you choose 52?
    – sherrellbc
    Jul 17 '15 at 6:09
  • @sherrellbc A lot of the default permission rules are at 50, so I used 52 to be a little after them.
    – derobert
    Jul 17 '15 at 6:11
  • Any idea why being in plugdev group lets me access mode 660 files which are owned root:plugdev, but being in dialout doesn't allow access to mode 660 files owned by root:dialout? I've checked this with ordinary files too. One clue: 'groups $USER' lists all the groups I'm in, but 'groups' (process groups) lists all the same groups except dialout. So 'dialout' group membership doesn't seem to apply to processes owned by me. I'm on ubuntu.
    – greggo
    May 19 '18 at 2:49
  • @greggo the processes groups are what actually matter, so that's why it doesn't work. The thing that comes to mind is if you didn't log out / back in after adding yourself to the group. Other than that, that's a good question, please ask it as a new question. (I haven't checked if it's already been asked, on a phone...)
    – derobert
    May 19 '18 at 5:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.