72

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?

Improve this question

7 Answers 7

Reset to default
100

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.

Improve this answer
2
  • 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, 2022 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 2, 2022 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
Improve this answer
3
  • 3
    This works, but I have to run it on every startup, otherwise I'll get the error again and again.
    – Krease
    Jan 10, 2018 at 21:52
  • Worked on my ubuntu running in windows 10
    – Griffin
    May 14, 2020 at 7:30
  • @Krease See the other answer to this. Worked for me on WSL Ubuntu 20 superuser.com/a/1556866/35931
    – Gnudiff
    Mar 31, 2022 at 8:56
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
Improve this answer
1
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.

Improve this answer
1
  • 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, 2022 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
Improve this answer
1
  • 2
    This is not a good solution. Every time you restart you have to redo this.
    – arupgsh
    Apr 8, 2019 at 20:46
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

Improve this answer
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, 2018 at 19:19
  • @Scott systemctl enable systemd-tmpfiles-setup.service that @Jacob suggested persisted across reboots.
    – Tagar
    Sep 11, 2018 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.

Improve this answer
1
  • 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 9 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .