77

Sometime, usually after a crash or sudden shutdown, screen refuses to start. Commands like

screen
screen -ls
screen -r
screen -d

result in the following output

Cannot make directory '/var/run/screen': Permission denied

What's the issue here? How can I fix this?

Marcin Magnus
  • 103
Huey
  • 1,559

7 Answers7

110

Found a solution that doesn't require regular sudo on restarts

From 'Eric Z Ma' @ systutorials:

The directory /var/run/screen/ is the socket directory for screen.

Fortunately, screen reads a environment variable SCREENDIR to get an alternative socket directory.

So to work around it, you can create a directory, such as ~/.screen:

mkdir ~/.screen && chmod 700 ~/.screen

and export the SCREENDIR to point to that directory:

export SCREENDIR=$HOME/.screen

You can also put this line into you ~/.bashrc so that it will also take effect afterwards.

Community
  • 1
Krease
  • 1,279
60

This issue has been documented here. In short,

/etc/rcS.d/S70screen-cleanup is running via upstart much earlier than it expects to have run, and is failing to correctly clean up that directory.

It can be fixed with the following command

sudo /etc/init.d/screen-cleanup start
Huey
  • 1,559
8

In my case the screen-cleanup service was masked, on Debian "buster" 10.4:

$ systemctl is-enabled screen-cleanup.service

masked

And

$ file /lib/systemd/system/screen-cleanup.service

/lib/systemd/system/screen-cleanup.service: symbolic link to /dev/null

Which causes the following:

$ systemctl enable screen-cleanup.service

Synchronizing state of screen-cleanup.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable screen-cleanup
Failed to enable unit: Unit file /lib/systemd/system/screen-cleanup.service is masked.

The following did the trick to create the run-directory on every boot. Remove the symlink to /dev/null manually (systemctl unmask didn't work):

rm /lib/systemd/system/screen-cleanup.service

Then enable the service:

systemctl enable screen-cleanup.service

And start it:

systemctl start screen-cleanup.service
Pieter Ennes
  • 229
  • 3
  • 6
5

I ran into this while running a Centos / RHEL 7 based distro, and it doesn't have anything named 'screen-cleanup' anywhere under /etc.

A workaround I found was to simply run sudo screen and then immediately exit from it.

After that I was able to run screen without any special privileges, so it appears to clean up /var/run approriately up when given the chance.

Jay Taylor
  • 307
4

I can fix this problem by executing the following commands.

sudo mkdir /var/run/screen
sudo chmod 777 /var/run/screen
Taichi Nakamura
  • 49
1

TL;DR: In Debian Stretch and later, make sure that systemd-tmpfiles-setup.service has been started successfully:

$:> systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled)
   Active: active (exited) since Thu 2018-06-21 19:54:06 CEST; 41min ago
   ...

If disabled (Loaded: ... ;disabled; ...) then you might want to enable it with systemctl enable systemd-tmpfiles-setup.service. If you want to use screen within a docker container then you either have to get systemd running in your container image or you have to run systemctl start systemd-tmpfiles-setup.service or /etc/init.d/screen-cleanup start (as suggested by Huey) each time after logging into your container.

Details: Since Debian Stretch, the startup script /etc/init.d/screen-cleanup is not executed, because by default this service is masked (/lib/systemd/system/screen-cleanup.service -> /dev/null), so systemd ignores it.

Instead systemd-tmpfiles-setup.service creates /run/screen on boot, as configured in /usr/lib/tmpfiles.d/screen-cleanup.conf: d /run/screen 0775 root utmp

Jakob
  • 11
1

This can happen when the root (/) directory is not owned by root, which causes the systemd-tmpfiles-setup.service service to fail.

Run cd / && ll to see who the owner of the root directory is.

Assuming it isn't root, run sudo chown root:root / to fix it.

Forrest Voight
  • 355