Bug 845671 - "Directory '/var/run/screen' must have mode 777." when opening screen
Summary: "Directory '/var/run/screen' must have mode 777." when opening screen
Status: CLOSED DUPLICATE of bug 844167
Alias: None
Product: Fedora
Classification: Fedora
Component: screen
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Lukáš Nykrýn
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-08-03 19:59 UTC by Andrew Wilcox
Modified: 2012-08-15 06:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-15 02:41:44 UTC
Type: Bug

Attachments (Terms of Use)
Patch to screen.spec that fixes this issue (1.44 KB, application/octet-stream)
2012-08-03 19:59 UTC, Andrew Wilcox
no flags Details

Description Andrew Wilcox 2012-08-03 19:59:14 UTC
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:

  screen.x86_64 0:4.1.0-0.11.20120314git3c2946.fc18                                                                               

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

How reproducible:

Steps to Reproduce:
From console:
1. $ sudo yum install screen
2. $ screen
Actual results:
"Directory '/var/run/screen' must have mode 777."

Expected results:
A new screen session is created.

Additional info:
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.

Comment 1 Lukáš Nykrýn 2012-08-04 07:03:51 UTC
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?

Comment 2 Charles R. Anderson 2012-08-14 19:00:21 UTC
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/

Comment 3 Charles R. Anderson 2012-08-14 19:01:36 UTC
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/

>mount|grep 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)

Comment 4 Charles R. Anderson 2012-08-14 19:06:16 UTC
This might explain the issue:

>rpm -qpl screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64.rpm |grep tmpfile

>cat /etc/tmpfiles.d/screen.conf 
# 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
	    Docs: man:tmpfiles.d(5)
	 Process: 953 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Comment 5 Charles R. Anderson 2012-08-14 19:12:33 UTC
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.

Comment 6 Charles R. Anderson 2012-08-15 02:41:44 UTC

*** This bug has been marked as a duplicate of bug 844167 ***

Comment 7 Lukáš Nykrýn 2012-08-15 06:57:15 UTC
Thanks for the investigation and update.

Note You need to log in before you can comment on or make changes to this bug.