Red Hat Bugzilla – Bug 845671
"Directory '/var/run/screen' must have mode 777." when opening screen
Last modified: 2012-08-15 02:57:15 EDT
Created attachment 602180 [details]
Patch to screen.spec that fixes this issue
Description of problem:
I had just installed screen for the first time on my Rawhide computer using yum. I received a lovely error when I tried to run it:
AWilcox on ind-wkst041 [pts/1 Fri 3 12:19] ~: screen
Directory '/var/run/screen' must have mode 777.
Version-Release number of selected component (if applicable):
Rawhide, yum update'd today, screen 4.1.0-0.11.20120314git3c2946.fc18
Steps to Reproduce:
1. $ sudo yum install screen
2. $ screen
"Directory '/var/run/screen' must have mode 777."
A new screen session is created.
Enclosed is a patch to screen.spec that fixes the .rpm and lets the user run screen as any user when the .rpm is installed, instead of having to chmod 777 the dir first.
This is exactly like #233527 and it was fixed before with the same type of patch.
Thanks for the report, but this was solved differently. Screen binary has setgid bit a owner group is screen, so it should be able to write into /var/run/screen. Can you please check permissions of your screen binary?
Same bug in fresh install/update of Fedora 17. I believe the directory doesn't survive reboots of the system, since it happened again after I rebooted.
Cannot make directory '/var/run/screen': Permission denied
>ls -l /usr/bin/screen
-rwxr-xr-x. 1 root root 437296 Mar 28 11:05 /usr/bin/screen*
>ls -ld /var/run/screen
ls: cannot access /var/run/screen: No such file or directory
>ls -ld /var/run
drwxr-xr-x. 37 root root 1320 Aug 14 14:51 /var/run/
Yes, systemd is now mounting /run as tmpfs, and there is a per-user /run, and /var/run symlinks to /run:
>ls -l /var/run
lrwxrwxrwx. 1 root root 6 Aug 13 17:15 /var/run -> ../run/
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
gvfs-fuse-daemon on /run/user/cra/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=10002,group_id=10002)
This might explain the issue:
>rpm -qpl screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64.rpm |grep tmpfile
# screen needs directory in /var/run
d /var/run/screen 0775 root screen
# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
Active: failed (Result: exit-code) since Tue, 14 Aug 2012 14:51:11 -0400; 13min ago
Process: 953 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE)
Tracing this further:
# /usr/bin/systemd-tmpfiles --create --remove
[/etc/tmpfiles.d/screen.conf:2] Unknown group 'screen'.
# getent group screen
# grep screen /etc/group
>rpm -qp --scripts screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64.rpm
preinstall scriptlet (using /bin/sh):
/usr/sbin/groupadd -g 84 -r -f screen
# ls -l /usr/sbin/groupadd
-rwxr-x---. 1 root root 59104 Jul 27 05:09 /usr/sbin/groupadd
So groupadd is failing in the %pre script. I /just/ encountered this very same issue with wireshark's %pre script as well.
*** This bug has been marked as a duplicate of bug 844167 ***
Thanks for the investigation and update.