Une récupération de cela? sudo chmod 600. *

AVERTISSEMENT - NE PAS EXÉCUTER LA COMMANDE MENTIONNÉE

Il semble donc que j'ai fait quelque chose d'assez stupide ici pour le dire doucement. J'essayais de changer les autorisations pour quelques fichiers dans un répertoire qui commençait tous .à lire / écrire pour sudo / root uniquement.

Ma tentative de changer plusieurs fichiers à la fois semble avoir fait quelque chose d'assez horriblement global. Alors que dans un répertoire (n'était pas dans le répertoire racine), j'ai couru sudo chmod 600 .*et bien, je le poste depuis mon téléphone maintenant ... J'ai toujours la fenêtre du terminal ouverte pour le moment, mais je suis sûr que si l'ordinateur portable va pour dormir j'ai complètement fini. De façon hilarante, cela signifie qu'il y a une légère urgence à cette question.

Oh, et cela semble avoir changé les autorisations presque partout, je suppose. Je ne peux même pas exécuter les commandes lsou cd ... Une tentative cd /home/brianou cd ~donner l'erreur bash: cd: /home/brian: Permission Deniedet toute tentative de sudocommande dit simplementbash: /usr/bin/sudo: Permission Denied

J'ai peur de redémarrer, aucun indice s'il y a une récupération intégrée de quelque chose d'aussi stupide, mais j'ai pensé que j'essaierais de demander ici avant d'aggraver les choses. Je suis un assez nouveau Linux car mon système d'exploitation principal se convertit et je le préconise un peu récemment, mais aïe, celui-ci pique un peu. Toute idée de choses à essayer serait grandement appréciée.

EDIT: Je voulais clarifier comment / où cette commande a été exécutée. Cela a été exécuté à partir d' /.atx $un répertoire arbitraire, mais plus de détails ci-dessous.

Pendant que j'étais connecté en tant que nom d'utilisateur normal brian, j'avais un terminal ouvert /.atxqui contenait trois fichiers texte de type configuration uniquement. Chaque nom de fichier a commencé par un .. Ce répertoire / nom / les fichiers ne font pas partie d'un package commun, juste un ensemble arbitraire de configurations que je déplaçais par programme. Les fichiers contenaient des informations sur la chaîne de connexion du serveur SQL et les voulaient simplement semi-obscurcies.

Ouf, la récupération ici a été en fait plus douce que ce à quoi je m'attendais et tout semble de nouveau en assez bon état.

Un grand merci à @CharlesGreen pour une explication de la façon dont cette commande a étendu un répertoire. Merci également à @Panther pour des informations sur le passage en mode de récupération pour un problème quelque peu lié. (si vous souhaitez tous les deux partager vos commentaires en tant que réponses, je les voterais favorablement)

Heureusement, contrairement au message lié, cela semble avoir eu une solution très simple. Il semble quand je courais la sudo chmod 600 .*commande d'un seul répertoire sous /elle a élargi l' .*UP partie aux véritables autorisations altérant répertoire racine de .de /causer tous les autres la permission de tomber.

Le «correctif» pour cela était de démarrer en mode de récupération, de remonter le lecteur en lecture / écriture, d'aller à la racine principale ( cd /), puis chmod +rx .. Après un redémarrage, tout semble redevenir normal.

Morale de l'histoire, l'exécution d'une commande sur .*peut au moins parfois avoir un impact sur le répertoire AU-DESSUS du courant. J'avais l'intention de n'impacter que les fichiers commençant par .... oups.

Un grand merci à tous ceux qui ont commenté et aidé.

Le "correctif" pour cela était de démarrer en mode de récupération, de remonter le lecteur en lecture / écriture, d'aller à la racine principale (cd /), puis de chmod + rx .. Après un redémarrage, tout semble être de retour à Ordinaire.

Juste pour être clair pour les futurs lecteurs qui pourraient trouver cela comme la réponse acceptée, il y a des préoccupations avec la chmod +xsolution comme solution générale. Cette question spécifique semble avoir été le répertoire de base des utilisateurs, donc certaines des préoccupations ci-dessous peuvent être faibles, mais si cela a été appliqué à un serveur d'entreprise et a affecté plusieurs utilisateurs ou d'autres répertoires de données, la solution n'est pas suggérée.

Du côté positif , cette étape permettrait à l'utilisateur de retrouver l'accès aux fichiers afin qu'ils puissent être copiés sur un support de sauvegarde pour éviter toute perte supplémentaire. Et à la fin de la journée, c'est l'objectif principal lors de tout effort de récupération de données.

La plus grande préoccupation est que les fichiers d'origine peuvent avoir eu des autorisations spécifiques appliquées qui sont maintenant manquantes. Certains programmes - en particulier ssh - appliquent les autorisations de fichiers pour garantir davantage leur sécurité et ne fonctionneront pas si l' +rwautorisation est définie sur son dossier et ses fichiers.

Une autre préoccupation est que si cela est appliqué au /dossier root ( ) de manière récursive, il y aura d'autres fichiers qui pourraient être ouverts pour que quiconque sur le système puisse les visualiser et les modifier. Dans un environnement professionnel où le serveur peut contenir des données sensibles (informations PCI / financières ou de santé / HIPAA), cet accès peut entraîner des résultats d'audit et des répercussions.

Dans un environnement personnel / domestique, cette récupération est probablement parfaitement acceptable. Notez simplement que certaines choses peuvent être brisées en silence ou agir bizarrement.

Dans un environnement professionnel, l'utilisation de cette récupération pour retrouver l'accès aux données peut être utilisée, mais en fin de compte, tout changement spectaculaire comme celui-ci doit être résolu en réinstallant le serveur et en récupérant à partir d'une sauvegarde.

( Vous avez une sauvegarde actuelle, n'est-ce pas? ;-) )