Toute récupération de cela? Sudo chmod 600. *
WARNING - DO NOT LANCER LA COMMANDE MENTIONNÉE
Il semble donc que j'ai fait quelque chose d'assez stupide pour le dire gentiment. J'essayais de modifier les autorisations de quelques fichiers d'un répertoire commençant par . afin de 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 (ce n’était pas le répertoire racine), j’exécutais Sudo chmod 600 .* et, j’envoie cette information à partir de mon téléphone maintenant ... J'ai toujours la fenêtre du terminal ouverte pour le moment, mais je suis sûr que l'ordinateur portable va dormir je suis complètement fait. Hilairement, cela signifie qu'il y a une légère urgence sur cette question.
Oh, et cela semble avoir changé les autorisations à peu près partout où je devine. Je ne peux même pas exécuter les commandes ls ou cd ... Une tentative de cd /home/brian ou cd ~ donne l'erreur bash: cd: /home/brian: Permission Denied et toute tentative d'utilisation d'une commande Sudo indique simplement bash: /usr/bin/Sudo: Permission Denied
J'ai peur de redémarrer, je ne sais pas s'il est possible de récupérer quelque chose d'aussi stupide, mais je me suis dit que j'essaierais de poser la question ici avant d'empirer les choses. Je suis un tout nouveau Linux, mon principal converti d’OS et le préconise un peu ces derniers temps, mais bon, celui-ci me pique un peu. Toute idée de choses à essayer serait immensément appréciée.
EDIT: Je voulais clarifier comment/où cette commande a été exécutée. Cela a été exécuté à partir de /.atx $, juste un répertoire arbitraire, mais plus de détails ci-dessous.
Bien que connecté sous mon nom d'utilisateur habituel, brian, j'avais un terminal ouvert à /.atx qui contenait trois fichiers contenant uniquement du texte de type config. Chaque nom de fichier commence par .. Ce répertoire/nom/les fichiers ne font pas partie d'un paquet commun, mais simplement d'un ensemble arbitraire de configs que je déplaçais par programme. Les fichiers contenaient des informations sur la chaîne de connexion du serveur SQL et voulaient simplement les semi-masquer.
Ouf, la reprise a été plus douce que ce à quoi je m'attendais et tout semble encore en très bonne forme.
Un grand merci à @CharlesGreen pour une explication de la manière 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 voulez tous les deux partager vos commentaires sous forme de réponses, je les inviterai à revenir)
Heureusement, contrairement au message lié, cela semble avoir eu une solution très simple. Il semble que lorsque j'ai exécuté la commande Sudo chmod 600 .* à partir d'un seul répertoire sous /, la partie .* a été étendue jusqu'au répertoire racine racine en modifiant les autorisations de . à partir de /, ce qui a entraîné la perte de toutes les autres autorisations.
La solution à ce problème consistait à démarrer en mode récupération, à remonter le lecteur en lecture/écriture, à accéder à la racine principale (cd /), puis à chmod +rx .. Après un redémarrage, tout semble revenir à la normale.
Morale de l'histoire, l'exécution d'une commande sur .* peut au moins parfois avoir une incidence sur le répertoire ABOVE the current. J'avais l'intention de ne toucher que les fichiers qui ont commencé avec .... oops.
Un grand merci à tous ceux qui ont commenté et aidé.
La solution à ce problème consistait à démarrer en mode récupération, à remonter le lecteur en lecture/écriture, à accéder à la racine principale (cd /), puis à chmod + rx .. Après un redémarrage, tout semble revenir à la racine. Ordinaire.
Soyons clairs pour les futurs lecteurs qui pourraient considérer cette solution comme acceptée, la solution chmod +x est généralement source de préoccupation. Cette question spécifique semble avoir été le répertoire de base des utilisateurs, de sorte que certaines des préoccupations ci-dessous peuvent être faibles. Toutefois, si cela a été appliqué à un serveur d'entreprise et a affecté plusieurs utilisateurs ou 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 afin d'éviter toute perte supplémentaire. Et en fin de compte, c'est l'objectif principal de tout effort de récupération de données.
La principale préoccupation est que des autorisations spécifiques ont été appliquées aux fichiers d'origine et sont maintenant manquantes. Certains programmes, en particulier ssh, appliquent des autorisations de fichier pour renforcer leur sécurité et ne fonctionneront pas si l’autorisation +rw est définie sur son dossier et ses fichiers.
Une autre préoccupation est que si cela est appliqué de manière récursive au dossier racine (/), d'autres fichiers seront peut-être ouverts et visualisables par tous les utilisateurs du système. 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 conduire à des constatations et des répercussions de l'audit.
Dans un environnement personnel/à domicile, cette reprise est probablement parfaitement acceptable. Il suffit de noter que certaines choses peuvent être brisées en silence ou se comporter étrangement.
Dans un environnement professionnel, vous pouvez utiliser cette récupération pour accéder à nouveau aux données, mais vous devez résoudre tout changement radical de ce type en réinstallant le serveur et en effectuant une récupération à partir d'une sauvegarde.
(Vous avez une sauvegarde actuelle, n'est-ce pas?; -))