Impossible de créer le répertoire '/ var / run / screen': autorisation refusée

26

Parfois, généralement après un crash ou un arrêt brutal, screenrefuse de démarrer. Des commandes comme

screen
screen -ls
screen -r
screen -d

entraîner la sortie suivante

Impossible de créer le répertoire '/ var / run / screen': autorisation refusée

Quel est le problème ici? Comment puis-je réparer cela?

ubuntu unix gnu-screen

— Huey
source

34

Trouvé une solution qui ne nécessite pas de sudo régulier au redémarrage

De 'Eric Z Ma' @ systutorials :

Le répertoire /var/run/screen/est le répertoire socket de screen.

Heureusement, screen lit une variable d'environnement SCREENDIRpour obtenir un autre répertoire de socket.

Pour contourner ce problème, vous pouvez créer un répertoire, tel que ~/.screen:
mkdir ~/.screen && chmod 700 ~/.screen
et exportez le SCREENDIRpour pointer vers ce répertoire:
export SCREENDIR=$HOME/.screen
Vous pouvez également mettre cette ligne en vous ~/.bashrcafin qu'elle prenne également effet par la suite.

— Krease
source

25

Ce problème a été documenté ici . En bref,

/etc/rcS.d/S70screen-cleanup s'exécute via upstart beaucoup plus tôt que prévu et ne parvient pas à nettoyer correctement ce répertoire.

Il peut être corrigé avec la commande suivante

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

— Huey
source

1

Cela fonctionne, mais je dois l'exécuter à chaque démarrage, sinon j'obtiendrai l'erreur encore et encore.

— Krease

3

J'ai rencontré cela lors de l'exécution d'une distribution basée sur Centos / RHEL 7, et il n'a rien nommé 'screen-cleanup' n'importe où sous / etc.

Une solution de contournement que j'ai trouvée consistait simplement à exécuter sudo screenpuis à en sortir immédiatement.

Après cela, j'ai pu exécuter l'écran sans aucun privilège spécial, il semble donc nettoyer / var / exécuter de manière appropriée lorsque l'occasion se présente.

— Jay Taylor
source

1

Je peux résoudre ce problème en exécutant les commandes suivantes.

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

— Taichi Nakamura
source

1

Ce n'est pas une bonne solution. Chaque fois que vous redémarrez, vous devez refaire cela.

— arupgsh

0

TL; DR : Dans Debian Stretch et versions ultérieures, assurez-vous que cela systemd-tmpfiles-setup.servicea été démarré avec succès:

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

Si désactivé ( Loaded: ... ;disabled; ...), vous pouvez l'activer avec systemctl enable systemd-tmpfiles-setup.service. Si vous souhaitez utiliser l'écran dans un conteneur Docker, vous devez soit exécuter systemd dans votre image de conteneur, soit exécuter systemctl start systemd-tmpfiles-setup.serviceou /etc/init.d/screen-cleanup start( comme suggéré par Huey ) à chaque fois après vous être connecté à votre conteneur.

Détails: Depuis Debian Stretch, le script de démarrage /etc/init.d/screen-cleanupn'est pas exécuté, car par défaut ce service est masqué ( /lib/systemd/system/screen-cleanup.service -> /dev/null), donc systemd l'ignore.

Au lieu de cela systemd-tmpfiles-setup.servicecrée /run/screenau démarrage, tel que configuré dans /usr/lib/tmpfiles.d/screen-cleanup.conf:d /run/screen 0775 root utmp

— Jakob
source

Il semble que vous proposiez (également) une procédure que l'OP devrait effectuer (manuellement) après chaque redémarrage. Pouvez-vous proposer une solution permanente, qui ne devrait être effectuée qu'une seule fois? Veuillez ne pas répondre dans les commentaires; modifiez votre réponse pour la rendre plus claire et plus complète.

— Scott

@Scott systemctl enable systemd-tmpfiles-setup.serviceque @Jacob a suggéré persistait lors des redémarrages.

— Tagar