dossier de départ 'inaccessible'
Parfois, lorsque je me connecte à mon serveur Ubuntu, l'invite indique jon@jon-server:(unreachable)/$. L'exécution de pwd à ce stade renvoie (unreachable)/, mais echo $HOME renvoie /home/jon comme prévu. Si je cd alors je suis pris dans mon dossier personnel.
Quelles pourraient en être les raisons? Cela ne semble pas poser de problème, mis à part l'authentification par clé publique avec SSH (sans doute, s'il ne peut pas voir le dossier de base, il ne peut pas accéder au dossier .ssh qu'il contient). Il semble être cohérent jusqu’à redémarrer - c’est-à-dire que chaque nouveau Shell le fera, jusqu’à ce que je le redémarre, qu’il fonctionne normalement ou non.
Cela se produit au moins pour les dernières mises à jour, donc sans rapport avec Oneiric. J'ai sélectionné l'option du programme d'installation pour chiffrer mon dossier personnel.
La question et la réponse pour Est-il possible d'utiliser la commande 'screen' pour travailler avec des fichiers sur un répertoire personnel crypté? m'a aidé à comprendre pourquoi ceci pourrait se produire: être connecté via screen avec ssh ne dit pas à Ubuntu que vous utilisez toujours le système. Ainsi, après un certain temps (toute la nuit dans mon cas), le répertoire personnel chiffré est démonté, de sorte que Vim ne peut pas sauvegarder les fichiers ouverts auparavant, et le répertoire de travail de l'invite de commande devient (unreachable).
Je sais que le problème disparaît si une session NX est connectée. NX peut être décrit comme un écran pour l'interface graphique. Je viens de démarrer une session NX et de la déconnecter (en la laissant exécuter l'arrière-plan), et je peux continuer à utiliser ssh/screen indéfiniment. Pas élégant ou idéal, mais j'utilise parfois NX, donc cela a fonctionné pour moi.
La question liée suggère également de supprimer le fichier vide dans /home/.ecryptfs/$USER/.ecryptfs/auto-umount. Cela pourrait aider si vous n'utilisez pas NX.
J'ai eu le même problème avec un dossier (inaccessible) trouvé dans ma machine Ubuntu distante avec un dossier personnel crypté.
Le problème concerne également tous les programmes qui s'exécutent en arrière-plan (dans mon cas, plusieurs instances de MATLAB ont nécessité la sauvegarde des espaces de travail).
J'ai définitivement résolu le problème en supprimant
/home/.ecryptfs/$USER/.ecryptfs/auto-umount
comme suggéré par Ahmed Fasih et rapporté dans est-il possible d'utiliser la commande 'screen' pour travailler avec des fichiers sur un répertoire personnel crypté? .
Je suggère de définir ce problème comme résolu et d’être une référence pour les autres utilisateurs car il n’ya pas d’autres réponses/sujets à ce sujet (et il m’a fallu beaucoup de recherche pour comprendre ce problème).
"J'ai sélectionné l'option du programme d'installation pour chiffrer mon dossier personnel."
Je dirais que c'est peut-être votre réponse. Je peux avoir cette erreur légèrement incorrecte car je n'utilise pas ecryptFS sur les machines que je n'utilise pas journalisées dans un environnement normal. Mais je pense que cela peut avoir quelque chose à voir avec le cryptage de votre répertoire personnel. Ainsi, son contenu n'est pas disponible, sauf si vous êtes connecté physiquement sur la console de la machine ou si vous avez spécifiquement monté/déchiffré le contenu du répertoire personnel.
Si vous allez sur/home/jon y a-t-il tout votre contenu, ou un lien README.txt et un petit lien .desktop pour vous aider à démarrer le processus de décryptage/montage?