ftdi usb serial node only accessible by root

[lanquarden]

After the upgrade to Kubuntu 10.10 I was not able connect to my buspirate (FTDI USB -> serial). Minicom reported:
minicom: cannot open /dev/buspirate: Device or resource busy

uname -a : Linux lorelei 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

This was working fine before the upgrade. At that time I had the following udev rule: 98-buspirate.rules
UBSYSTEM=="tty", ATTRS{serial}=="A7004DMs", GROUP="users", MODE="0660", SYMLINK+="buspirate"

I thought it could have something to do with the rule so I removed it and reloaded the udev rules:
sudo udevadm control --reload-rules

Then again I could acces /dev/ttyUSB0 as normal user.

Today after a reboot I wanted to access my buspirate through minicom (udev rule removed) and could not access /dev/ttyUSB0:
minicom: cannot open /dev/ttyUSB0: Device or resource busy

I checked the permissions:
ping@lorelei:~$ ls -al /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 2010-10-18 20:52 /dev/ttyUSB0

Group membership:
ping@lorelei:~$ groups
ping adm dialout cdrom plugdev users lpadmin admin sambashare vboxusers

Even added myself to the uucp group but to nothing changed. Tried reloading the ftdi_sio kernel module but didn't help.

dmesg entries look normal I think:
[ 7795.737299] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 7795.737309] ftdi_sio 6-2:1.0: device disconnected
[ 7798.963590] usb 6-2: new full speed USB device using uhci_hcd and address 8
[ 7799.178150] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
[ 7799.178188] usb 6-2: Detected FT232RL
[ 7799.178192] usb 6-2: Number of endpoints 2
[ 7799.178196] usb 6-2: Endpoint 1 MaxPacketSize 64
[ 7799.178199] usb 6-2: Endpoint 2 MaxPacketSize 64
[ 7799.178203] usb 6-2: Setting MaxPacketSize 64
[ 7799.179162] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0

I did an strace of minicom to see if I got any wiser:
....
stat("/var/lock", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0
open("/var/lock/LCK..ttyUSB0", O_RDONLY) = -1 ENOENT (No such file or directory)
umask(022) = 022
open("/var/lock/LCK..ttyUSB0", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
getpid() = 10590
write(3, " 10590\n", 11) = 11
close(3) = 0
umask(022) = 022
rt_sigaction(SIGALRM, {0x4199f0, [ALRM], SA_RESTORER|SA_RESTART, 0x7f42a5850c20}, {SIG_DFL, [], 0}, 8) = 0
alarm(4) = 0
open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
alarm(0) = 4
rt_sigaction(SIGALRM, {SIG_IGN, [ALRM], SA_RESTORER|SA_RESTART, 0x7f42a5850c20}, {0x4199f0, [ALRM], SA_RESTORER|SA_RESTART, 0x7f42a5850c20}, 8) = 0
....
Permissions of /var/lock can't be the cause...

Using sudo I can access the buspirate, but I want to run my programs as a regular user...

I did notice that connecting through minicom to /dev/ttyS0 with the same permissions is successful.

[lanquarden (lanquarden)]

I found the culprit, modem-manager...

I loaded the ftdi_sio driver with debugging enabled. While searching the syslog (did not check it yesterday) for debugging output from the driver I found that from the moment I plugged the buspirate in, modem-manager opened the port for some reason. Effectively locking the port, this without putting a lock file in /var/lock.

I removed modem-manager and could use my buspirate again.

Maybe it would be could if modem-manager puts a lockfile in /var/lock when opening a serial port.....

[komputes (komputes)]

Is this a feature request to put a lockfile in /var/lock when opening a serial port?

Would the kernel be responsible for creating this file?

[lanquarden (lanquarden)]

The kernel should not create the lock file, it is the program that should do that, ie modem-manager. Creating the lock file lets other programs that want to use the same serial port know that the port is in use. This file makes it also easy to identify the program using the port.

I guess this is some kind of feature request concerning modem-manager, or maybe a bug because it connects automatically to serial ports without permission of the user.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release http://cdimage.ubuntu.com/daily-live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]