Qualche recupero da questo? sudo chmod 600. *

AVVERTENZA - NON ESEGUIRE IL COMANDO Citato

Quindi sembra che abbia fatto qualcosa di piuttosto stupido qui per dirla in modo lieve. Stavo tentando di cambiare i permessi per alcuni file in una directory che tutti hanno iniziato .a leggere / scrivere solo per sudo / root.

Il mio tentativo di cambiare più file contemporaneamente sembra aver fatto qualcosa di orribilmente globale. Mentre ero all'interno di una directory (non era nella directory principale) ho funzionato sudo chmod 600 .*e bene, sto postando questo dal mio telefono ora ... Al momento ho ancora la finestra del terminale aperta, ma sono abbastanza sicuro se il laptop va a dormire ho finito. Esilarante significa che c'è una leggera urgenza in questa domanda.

Oh, e questo sembra aver cambiato le autorizzazioni maledettamente vicino dappertutto, suppongo. Non riesco nemmeno a eseguire i comandi lso cd ... Un tentativo di cd /home/briano cd ~dare l'errore bash: cd: /home/brian: Permission Deniede qualsiasi tentativo di un sudocomando dice semplicementebash: /usr/bin/sudo: Permission Denied

Ho paura di riavviare, nessun indizio se c'è qualcosa di integrato da qualcosa di così stupido, ma ho pensato che avrei cercato di chiedere qui prima di peggiorare le cose. Sono un Linux abbastanza nuovo mentre il mio sistema operativo principale si converte e lo sto sostenendo un po 'di recente, ma ahi, questo punge un po'. Qualsiasi pensiero sulle cose da provare sarebbe immensamente apprezzato.

EDIT: Volevo fornire chiarimenti su come / dove è stato eseguito questo comando. Questo è stato eseguito da /.atx $, solo una directory arbitraria, ma ulteriori dettagli di seguito.

Durante l'accesso come mio normale nome utente brian, avevo un terminale aperto /.atxche conteneva tre file di solo testo di tipo config. Ogni nome file è iniziato con a .. Quella directory / nome / i file non fanno parte di un pacchetto comune, ma solo un insieme arbitrario di configurazioni che stavo spostando programmaticamente. I file contenevano alcune informazioni sulla stringa di connessione del server SQL e le volevano solo semi-oscurate.

Accidenti, il recupero qui è stato in effetti più fluido di quanto mi aspettassi e tutto sembra SEMPRE di nuovo in buona forma.

Enorme grazie a @CharlesGreen per una spiegazione di come quel comando ha esteso una directory. Anche grazie a @Panther per informazioni su come accedere alla modalità di ripristino per un problema in qualche modo correlato. (se entrambi volete condividere nuovamente i vostri commenti come risposte, li voterei)

Fortunatamente, a differenza del post collegato, questo sembra aver avuto una soluzione molto semplice. Sembra che quando ho eseguito il sudo chmod 600 .*comando da una sola directory sotto di /essa ha espanso la .*porzione UP nella directory principale vera alterando le autorizzazioni .da /causare la caduta di ogni altra autorizzazione.

La "soluzione" per questo era di avviare in modalità di ripristino, ricollegare l'unità come lettura / scrittura, andando alla radice principale ( cd /) e quindi chmod +rx .. Dopo un riavvio, tutto sembra tornare alla normalità.

Morale della storia, eseguendo un comando su .*almeno qualche volta può avere un impatto sulla directory SOPRA la corrente. Avevo intenzione di influenzare solo i file che erano iniziati con .... oops.

Grazie enormi a tutti coloro che hanno commentato e aiutato.

La "soluzione" per questo era di avviare in modalità di ripristino, ricollegare l'unità come lettura / scrittura, andare alla radice principale (cd /) e quindi chmod + rx .. Dopo un riavvio, tutto sembra tornare a normale.

Giusto per essere chiari per i futuri lettori che potrebbero trovarlo come la risposta accettata, ci sono dubbi sulla chmod +xsoluzione come soluzione generale. Questa domanda specifica sembra essere la home directory degli utenti, quindi alcune delle preoccupazioni di seguito potrebbero essere basse, ma se questa è stata applicata a un server aziendale e ha avuto un impatto su più utenti o altre directory di dati, la soluzione non è suggerita.

Sul lato positivo , questo passaggio consentirebbe all'utente di riottenere l'accesso ai file in modo che possano essere copiati su un supporto di backup per evitare ulteriori perdite. E alla fine della giornata, questo è l'obiettivo principale durante qualsiasi sforzo di recupero dei dati.

La preoccupazione maggiore è che ai file originali potrebbero essere state applicate autorizzazioni specifiche che ora mancano. Alcuni programmi, in particolare ssh, impongono le autorizzazioni dei file per garantire ulteriormente la loro sicurezza e non funzioneranno se l' +rwautorizzazione è impostata sulla sua cartella e sui suoi file.

Un'altra preoccupazione è se questo viene applicato nella /cartella root ( ) in modo ricorsivo, ci saranno altri file che potrebbero essere aperti a chiunque nel sistema per visualizzare e modificare. In un ambiente aziendale in cui il server potrebbe contenere dati sensibili (informazioni PCI / finanziarie o sanitarie / HIPAA) questo accesso potrebbe portare a risultati e ripercussioni dell'audit.

In un ambiente personale / domestico questo recupero è probabilmente perfettamente accettabile. Basta notare che alcune cose potrebbero essere rotte silenziosamente o agire in modo strano.

In un ambiente aziendale, è possibile utilizzare questo ripristino per riottenere l'accesso ai dati, ma alla fine qualsiasi cambiamento drammatico come questo dovrebbe essere risolto reinstallando il server e ripristinando da un backup.

( Hai un backup attuale, vero? ;-) )