70

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
  • 2
Huey
  • 1,431
  • 1
  • 11
  • 17

7 Answers7

98

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,159
  • 8
  • 12
  • 3
    On WSL-Ubuntu 20.04 I fixed this by creating file `/etc/profile.d/screen.sh` containing the line `export SCREENDIR=$HOME/.local/run/screen`. This should solve the issue for all users on that machine. – blerontin Jul 14 '22 at 11:52
  • 3
    improving @blerontin answer, my /etc/profile.d/screen.sh (created and edited by root) is: #!/bin/bash mkdir -p $HOME/.local/run/screen chmod 700 $HOME/.local/run/screen export SCREENDIR=$HOME/.local/run/screen – Marco Guardigli Nov 02 '22 at 10:44
54

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,431
  • 1
  • 11
  • 17
6

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
  • 209
  • 3
  • 6
  • This solution would be nicer, but it brings other problems for WSL machines, since they [might not have systemd](https://askubuntu.com/a/1379567/1424714). – Giancarlo Sportelli Dec 22 '22 at 18:33
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
  • 231
  • 4
  • 9
  • Also had to `sudo chmod 777 /run/screen` after the initial `sudo screen` and then works fine **without** `sudo` , i.e. third time lucky. Only did this because on the second try it told me `Directory '/run/screen' must have mode 777.` – Nagev Jan 19 '22 at 15:58
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
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
  • 2
  • It looks like you are (also) suggesting a procedure that the OP would need to perform (manually) after every reboot. Can you offer a permanent solution, that would need to be done only once? Please do not respond in comments; [edit] your answer to make it clearer and more complete. – Scott - Слава Україні Jun 21 '18 at 19:19
  • @Scott `systemctl enable systemd-tmpfiles-setup.service` that @Jacob suggested persisted across reboots. – Tagar Sep 11 '18 at 15:43
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
  • 315
  • 3
  • 4
  • I'm not sure what the `ll` command is and I don't seem to have it, but I ran `getfacl /` and it indeed informed me my user owned /, whoops! Thank you :) – keithzg Apr 09 '23 at 00:01