无法创建目录'/ var / run / screen'：权限被拒绝

有时，通常在崩溃或突然关机后，screen拒绝启动。像这样的命令

screen
screen -ls
screen -r
screen -d

导致以下输出

无法创建目录'/ var / run / screen'：权限被拒绝

这是什么问题？我怎样才能解决这个问题？

找到了一个在重启时不需要定期sudo的解决方案

来自'Eric Z Ma'@ systutorials：

该目录/var/run/screen/是屏幕的套接字目录。

幸运的是，屏幕读取环境变量SCREENDIR以获取备用套接字目录。

因此，要解决它，您可以创建一个目录，例如~/.screen：

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

并导出SCREENDIR指向该目录：

export SCREENDIR=$HOME/.screen

您也可以将此行放入您的行中，~/.bashrc以便之后也能生效。

此问题已在此处记录。简而言之，

/etc/rcS.d/S70screen-cleanup 通过upstart运行比它预期运行的更早，并且无法正确清理该目录。

可以使用以下命令修复它

sudo /etc/init.d/screen-cleanup start

我在运行基于Centos / RHEL 7的发行版时遇到了这个问题，它在/ etc下没有任何名为'screen-cleanup'的东西。

我找到的解决方法是简单地运行sudo screen然后立即退出它。

之后，我能够在没有任何特殊权限的情况下运行屏幕，因此在有机会的情况下，似乎可以清理/ var / run。

TL; DR：在Debian Stretch中以及稍后，确保systemd-tmpfiles-setup.service已成功启动：

$:> 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
   ...

如果禁用（Loaded: ... ;disabled; ...），则可能需要启用它systemctl enable systemd-tmpfiles-setup.service。如果您想在docker容器中使用screen，那么您必须在容器映像中运行systemd，或者每次登录容器后都必须运行systemctl start systemd-tmpfiles-setup.service或/etc/init.d/screen-cleanup start（如Huey所建议的那样）。

详细信息：自Debian Stretch以来，启动脚本/etc/init.d/screen-cleanup未执行，因为默认情况下此服务是masked（/lib/systemd/system/screen-cleanup.service -> /dev/null），因此systemd忽略它。

而是在启动时systemd-tmpfiles-setup.service创建/run/screen，如下所示/usr/lib/tmpfiles.d/screen-cleanup.conf：d /run/screen 0775 root utmp

我可以通过执行以下命令来解决此问题。

sudo mkdir /var/run/screen
sudo chmod 777 /var/run/screen