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

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?


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
  • 1
    This works, but I have to run it on every startup, otherwise I'll get the error again and again. – Krease Jan 10 '18 at 21:52

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.


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.


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

  • 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

I can fix this problem by executing the following commands.

sudo mkdir /var/run/screen
sudo chmod 777 /var/run/screen
New contributor
Taichi Nakamura is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.