Bug 2385964

Summary:	Directory '/run/screen' must have mode 777
Product:	[Fedora] Fedora EPEL	Reporter:	Martin Osvald 🛹 <mosvald>
Component:	screen	Assignee:	Josef Ridky <jridky>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	epel10	CC:	adam.winberg, bvitnik, gerd, jridky, lnykryn, phracek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Osvald 🛹 2025-08-01 15:28:32 UTC

This bug was initially created as a copy of Bug #2313752

I am copying this bug because: 

It also happens on RHEL10:

~~~
 ~]# screen
Directory '/run/screen' must have mode 777.
 ~]# rpm -q screen
screen-5.0.1-4.el10_1.x86_64
 ~]#
~~~


I'm unable to run screen in Fedora 40 on arm(Raspberry PI 4) due to an error:
Directory '/var/run/screen' must have mode 777

screen version:
Screen version 4.09.01 (GNU) 20-Aug-23


Reproducible: Always

Steps to Reproduce:
1.run screen -ls as user
2.
3.
Actual Results:  
Directory '/run/screen' must have mode 777

Expected Results:  
screen works


systemctl status systemd-tmpfiles-setup fails due to:

Sep 11 00:00:11 Silverhead-pi.local systemd[1]: Starting systemd-tmpfiles-setup.service - Create System Files and Directories...
Sep 11 00:00:11 Silverhead-pi.local systemd-tmpfiles[634]: /usr/lib/tmpfiles.d/screen.conf:2: Failed to resolve group 'screen': No such process

and 
/usr/lib/tmpfiles.d/screen.conf contains permission 0775

after manually adding group screen and edits of /usr/lib/tmpfiles.d/screen.conf it works

Comment 1 adam winberg 2026-01-14 10:03:07 UTC

Also seeing this. The 'screen' group is supposed to be added via sysuser magic in the rpm spec file, but this happens too late - the group is created after the rpm package installs the files and tries to set owner/permissions. 

A reinstall of the screen package solves the problem (since the 'screen' group then already exists), but the spec file needs to be fixed to work with rpm version on RHEL.

Comment 2 Gerd v. Egidy 2026-04-15 15:00:44 UTC

I'm also affected by this.

@adam: thanks for your explanation, after doing a "dnf reinstall screen" it works.

I would still prefer a proper fix in the RPM as I now have to automate the workaround for all installs I want screen on...

Comment 3 Bojan Vitnik 2026-07-13 21:59:08 UTC

Hi all. I can confirm this problem. Got bitten by it today while testing our automation against RHEL 10.

There is one thing I would like to clarify additionally. Ownership and permissions of the "/run/screen" directory are only half of the problem. They will be corrected after a single reboot because at that point "/run" will be repopulated by tmpfiles.d. Since "screen" group at that point now exists, the correct ownership and permissions will be set.

The other half of the problem is with the ownership and permissions of the "/usr/bin/screen" executable. Per .spec file they should be "root:screen", for ownership, and "2755" for permissions (set gid bit is set). This, combined with "0775" permissions on "/run/screen", results in working combination. Unfortunately both fail because of the missing group "screen". at that point in time.

In a nutshell, the problem with "/run/screen" is solved with restart. The problem with "/usr/bin/screen" is solved by reinstalling the package or manually running "chown root:screen /usr/bin/screen && chmod 2755 /usr/bin/screen".

Note: "/usr/lib/tmpfiles.d/screen.conf" should not be edited because it will be overwritten by the package upgrade.