@mcc The group list is part of a process's state (like the uid and primary gid); changing /etc/group won't affect an existing session. That's probably why rebooting fixed it; logging out and back in also would've, or sudo'ing to yourself (like what I did the last time I had to add myself to a group for something and was too lazy to log out), or maybe newgrp.
This is also the difference between id without a username (shows the calling process's actual credentials) and id with a username (shows what creds the user would get if they logged in anew, basically).
@mcc …so uh, somehow I completely failed to see the sentence where you said you'd tried that. My sincere apologies for being the online rando who gives bad advice.
I thought I knew all the ways this corner of computer could be broken but maybe someone invented new ones? My guess is that it's not about the dialout group in particular and there's some additional level of user-information cache, like nscd or maybe some new systemd thing, but at this point I'm not sure how much I should trust my intuition here.
@mcc@xlerb I've seen selinux and apparmor policies cause inexplicable failures like this, but I haven't had any problems with dialout specifically on ubuntu (I do a lot of ttyUSB access on ubuntu systems). I'm only on 22.04 LTS tho, I think you're on a more recent release...
There might be audit messages in syslog if it's policy related.
I can say, on 22.04 doing usermod -aG dialout , then logging out and back in, suffices for ttyUSB, a reboot is not required. I've done exactly this on at least 4 systems in the last 3 months. If they've added some new hoop on 23 I guess I'll find out soon enough ...
@mcc There’s some command you can run to make the system pick up the change… but I’ve just rebooted the last few times it’s come up since you’ll never find it faster than that. (Shrug)
Add comment