Não é possível criar o diretório '/ var / run / screen': permissão negada

26

Em algum momento, geralmente após um acidente ou um desligamento repentino, screense recusa a iniciar. Comandos como

screen
screen -ls
screen -r
screen -d

resultar na seguinte saída

Não é possível criar o diretório '/ var / run / screen': permissão negada

Qual é o problema aqui? Como posso consertar isso?

ubuntu unix gnu-screen

— Huey
fonte

34

Foi encontrada uma solução que não requer sudo regular ao reiniciar

De 'Eric Z Ma' @ systutorials :

O diretório /var/run/screen/é o diretório do soquete para a tela.

Felizmente, a tela lê uma variável de ambiente SCREENDIRpara obter um diretório de soquete alternativo.

Portanto, para contornar isso, você pode criar um diretório, como ~/.screen:
mkdir ~/.screen && chmod 700 ~/.screen
e exporte o SCREENDIRpara apontar para esse diretório:
export SCREENDIR=$HOME/.screen
Você também pode inserir esta linha em você, ~/.bashrcpara que ela também entre em vigor posteriormente.

— Krease
fonte

25

Este problema foi documentado aqui . Em resumo,

/etc/rcS.d/S70screen-cleanup está executando via iniciante muito mais cedo do que espera executar e não está conseguindo limpar corretamente esse diretório.

Pode ser corrigido com o seguinte comando

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

— Huey
fonte

1

Isso funciona, mas eu tenho que executá-lo em toda inicialização, caso contrário, receberei o erro novamente e novamente.

— Krease

3

Eu me deparei com isso enquanto executava uma distro baseada em Centos / RHEL 7, e ela não tem nada chamado 'limpeza de tela' em qualquer lugar em / etc.

Uma solução alternativa que encontrei foi simplesmente executar sudo screene sair imediatamente dela.

Depois disso, eu fui capaz de executar a tela sem privilégios especiais, de modo que parece limpar / var / run de maneira apropriada quando tiver a chance.

— Jay Taylor
fonte

1

Eu posso corrigir esse problema executando os seguintes comandos.

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

— Taichi Nakamura
fonte

1

Esta não é uma boa solução. Toda vez que você reiniciar, você precisará refazer isso.

— arupgsh

0

TL; DR : No Debian Stretch e posterior, verifique se systemd-tmpfiles-setup.servicefoi iniciado com sucesso:

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

Se desativado ( Loaded: ... ;disabled; ...), convém ativá-lo systemctl enable systemd-tmpfiles-setup.service. Se você deseja usar a tela em um contêiner de docker , é necessário executar o systemd na imagem do contêiner ou executar systemctl start systemd-tmpfiles-setup.serviceou /etc/init.d/screen-cleanup start( como sugerido por Huey ) sempre que efetuar o logon no contêiner.

Detalhes: Desde o Debian Stretch, o script de inicialização /etc/init.d/screen-cleanupnão é executado, porque por padrão este serviço está mascarado ( /lib/systemd/system/screen-cleanup.service -> /dev/null), pelo que o systemd o ignora.

Em vez disso, systemd-tmpfiles-setup.servicecria /run/screenna inicialização, conforme configurado em /usr/lib/tmpfiles.d/screen-cleanup.conf:d /run/screen 0775 root utmp

— Jakob
fonte

Parece que você (também) está sugerindo um procedimento que o OP precisaria executar (manualmente) após cada reinicialização. Você pode oferecer uma solução permanente, que precisaria ser feita apenas uma vez? Por favor, não responda nos comentários; edite sua resposta para torná-la mais clara e completa.

— Scott

O @Scott systemctl enable systemd-tmpfiles-setup.serviceque @Jacob sugeriu persistiu durante as reinicializações.

— Tagar