Minicom is not able to create a lockfile. I run minicom in Leap 15.6 as regular user, user is part of dialout group, /dev/ttyUSB0 or /dev/ttyS0 group is dialout.
“Cannot create lockfile for /dev/ttyS0: Permission denied”
groups
users tty uucp dialout plugdev
ls -la /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 7. aug 12:24 /dev/ttyS0
It looks like there is something with either /run/lock or /var/lock
In OpenSUSE 15.3 I had no problems. There I had:
/var/lock:
lrwxrwxrwx 1 root root 9 12. aug 2021 lock → /run/lock
/run/lock:
drwxrwxr-x 5 root lock 120 7. aug 12:11 lock
(Notice lock group in OpenSUSE 15.3; however, user was not in lock group)
/var/lock in OpenSUSE 15.6:
lrwxrwxrwx 1 root root 9 2. juuli 10:44 /var/lock → /run/lock
/run/lock in OpenSUSE 15.6:
drwxrwxr-x 5 root root 140 7. aug 12:35 lock
In OpenSUSE 15.6, I can only use Minicom if I change permissions of /run/lock to 777:
sudo chmod 0777 /run/lock
Maybe there are other workarounds…
Maybe minicom is now using /run/lock instead of /var/lock and this makes minicom unusable for regular user (as they have to have rights to change /run/lock permissions).
First, please, use preformatted text to post computer messages. Second, always post the complete command and its output as you did for /dev/ttyS0. The output above is highly ambiguous. Is it symlink lockinside of /run/lock? Is it /run/lock itself?
I’m sorry, I didn’t notice the gray bar on top of the textbox. Thanks.
ls -la /var | grep lock
lrwxrwxrwx 1 root root 9 2. juuli 10:44 lock -> /run/lock
ls -la /run | grep lock | tail -n 1
drwxrwxr-x 5 root root 140 7. aug 12:55 lock
I probably could make a workaround there, thanks. I actually don’t believe it’s correct to put 0777 permissions to /run/lock.
My worry is that actually there is something wrong with how minicom behaves. Maybe it should attempt to create a lockfile to /var/lock (because it seems to have permissions for it) rather than /run/lock. Or does minicom need to be in the same group as /run/lock. I don’t know.
Minicom doesn’t start by default when the lockfile can’t be created. As a user without root access this will be solvable only by running
# minicom setup without checking for lockfile:
minicom -s -o
# or, if correct port is already set up (saved as default), run:
minicom -o
(minicom -o means don’t initialize = don’t check for lockfile)
So, what I ended up doing, was the change in suse.conf. I ran the command grep to find /run/lock permissions:
# grep -r /run/lock /usr/lib/tmpfiles.d/
/usr/lib/tmpfiles.d/dmraid.conf:d /run/lock/dmraid 0700 root root -
/usr/lib/tmpfiles.d/lvm2.conf:d /run/lock/lvm 0700 root root -
/usr/lib/tmpfiles.d/systemd-suse.conf:d /run/lock 0775 root root -
/usr/lib/tmpfiles.d/systemd-suse.conf:# /run/lock/subsys is used for serializing SysV service execution, and
/usr/lib/tmpfiles.d/systemd-suse.conf:d /run/lock/subsys 0755 root root -
The line I was looking for is in /usr/lib/tmpfiles.d/systemd-suse.conf (seems that it has changed from 15.5 and 15.3). I copied it to /etc/tmpfiles.d/
sudo cp /usr/lib/tmpfiles.d/systemd-suse.conf /etc/tmpfiles.d/
sudo nano /etc/tmpfiles.d/systemd-suse.conf
# Changed line 10 from
d /run/lock 0775 root root -
# to
d /run/lock 0775 root lock -
This is enough for minicom to work. Why has the group changed? Maybe because it was moved from suse.conf to systemd-suse.conf, it wasn’t copy-pasted. Or maybe there’s another reason that lock shouldn’t be in lock group, but in root group.
# ls -l $(which minicom)
-rwxr-xr-x 1 root uucp 209864 25. mai 2018 /usr/bin/minicom
It’s exactly the same for both 15.6 and 15.3.
So, although I don’t know why, but having the folder “/run/lock” in “lock” group is enough for minicom to be able to work correctly (at least without strace) and create the lockfile.
I think it works because minicom is using the /usr/sbin/lockdev to get the lock and this is a setgid binary.
# ls -l /usr/sbin/lockdev
-rwxr-sr-x 1 root lock 10480 May 25 2018 /usr/sbin/lockdev
If you use strace with a setuid/setgid binary the setuid/setgid bit will be ignored.
If you run strace as root with the -u option the setgid bit should be not ignored
From your last strace.log you can see that minicom is calling /usr/sbin/lockdev to lock
> grep 8871 strace.log
and unlock the serial device.
> grep 8873 strace.log
So having /run/lock in the lock group is the right approach for this problem on Leap 15.6 in my opinion. I am not sure if Leap 15.6 default permissions of /run/lock is a bug or intended. It might be worth to open a bug report.
Just for info the Tumbleweed minicom version does not use lockdev anymore it seems that lockdev is not available for Tumbleweed anymore. So your fix will not work with Tumbleweed.