Any recovery from this? sudo chmod 600 .*

WARNING - DO NOT RUN THE MENTIONED COMMAND

So it seems I did something pretty dumb here to put it mildly. I was attempting to change the permissions for a few files in a directory that all started with . to read/write for sudo/root only.

My attempt at changing several files at once seems to have done something pretty horribly global. While inside a directory (wasn't at root dir) I ran sudo chmod 600 .* and well, I'm posting this from my phone now... I still have the terminal window open at the moment, but I'm quite sure if the laptop goes to sleep I'm completely done. Hilariously that means there is a slight urgency to this question.

Oh and this seems to have changed permissions damn near everywhere I'm guessing. I can't even run the ls or cd .. commands. An attempt of cd /home/brian or cd ~ give the error bash: cd: /home/brian: Permission Denied and any attempt at a sudo command just says bash: /usr/bin/sudo: Permission Denied

I am afraid of rebooting, no clue if there is any built in recover from something this dumb, but figured I would try to ask here before making things any worse. I'm a pretty new Linux as my main OS convert and been advocating for it a bit lately, but ouch, this one stings a bit. Any thoughts of things to try would be immensely appreciated.

EDIT: I wanted to provide clarification on how/where this command was executed. This was executed from /.atx $, just an arbitrary directory, but more details below.

While logged in as my regular username brian, I had a terminal open to /.atx that contained three config type text only files. Each filename started with a .. That directory/name/the files aren't any part of a common package, just an arbitrary set of configs I was programmatically moving around. Files contained some SQL server connection string info and just wanted them semi-obscured.

Solution 1:

Whew, the recovery here was actually smoother than I expected and everything SEEMS in pretty good shape again.

Huge thanks to @CharlesGreen for an explanation of how that command extended up a directory. Also thanks to @Panther for info on getting into recovery mode for a somewhat related issue. (if you both want to re-share your comments as answers I'd upvote them)

Fortunately, unlike the linked post, this seems to have had a very straightforward fix. It seems when I ran the sudo chmod 600 .* command from only one directory under / it expanded the .* portion UP to the true root directory altering permissions of . from / causing every other permission to fall over.

The "fix" for this was to boot into recovery mode, re-mounting the drive as read/write, going to the main root (cd /), and then chmod +rx .. After a reboot, everything looks to be back to normal.

Moral of the story, executing a command on .* can at least sometimes impact the directory ABOVE the current. I had intended to only impact files that started with ....oops.

Huge thanks to everyone that commented and helped.

Solution 2:

The "fix" for this was to boot into recovery mode, re-mounting the drive as read/write, going to the main root (cd /), and then chmod +rx .. After a reboot, everything looks to be back to normal.

Just to be clear for future readers who might come across this as the accepted answer, there are concerns with the chmod +x solution as a general solution. This specific question appears to have been the users home directory so some of the concerns below may be low, but if this was applied to a business server and impacted multiple users or other data directories the solution is not suggested.

On the positive side, this step would permit the user to regain access to the files so they can be copied off to a backup medium to prevent further loss. And at the end of the day, that's the primary goal during any data recovery effort.

The biggest concern is that the original files might have had specific permissions applied that are now missing. Some programs - specifically ssh - enforce file permissions to further ensure their security and will not work if the +rw permission is set on its folder and files.

Another concern is if this is applied at the root (/) folder recursively, there will be other files that might be open for anyone on the system to view and modify. In a business setting where the server might contain sensitive data (PCI/financial, or healthcare/HIPAA information) this access could lead to audit findings and repercussions.

In a personal/home environment this recovery is probably perfectly acceptable. Just note that some things might be silently broken or act weirdly.

In a business environment, using this recovery to regain access to the data might be used, but ultimately any dramatic change like this should be resolved by re-installing the server and recovering from a backup.

( You DO have a current backup, don't you? ;-) )