My installation just LOST most of its system utilities and permissions
 

[URL="https://www.reddit.com/r/linuxquestions/comments/8ctio8/extremely_confused_my_installation_just_most_of/"]Cross posting from reddit[/URL]:

[quote]
Not sure how else to describe it, but suddenly, in the course of normal usage, my system started behaving in the strangest way. First I noticed the system clock forgot the local time zone -- so I clicked on the calendar app, only to be told that permission was denied to launch the relevant executable. I couldn't create new browser tabs, I couldn't open new terminals, I couldn't launch the System Monitor, all the icons disappeared from the start menu, most of the icons disappeared from my tray, all sorts of wacky stuff.

So I Alt+F1d to a lower terminal, which worked, except for when it didn't:

`top`

command not found

`ps`

permission denied to load some shared library (forget which)

`which top`

(nothing)

`locate top`

locate: command not found

`sudo shutdown -h now`

sudo: command not found

`poweroff`

poweroff: command not found

`init 0`

init: command not found

`sudo init 0`

sudo: command not found

su doesn't work because there's no root account, and of course sudo su fails the same as above

`less /var/log/kern.log`

permission denied (not surprising, but frustrating since i can't become root)

Things like ls or cd or grep still work fine, it's the more import system stuff that seems to be fucked up somehow. And for some of them it's not just missing, but being denied permission to load shared libraries.

wtf could cause this? The only proximate thing I can think of in my browsing is that just before this, I ran the `sudo checkinstall ....` command from the OBS Studio [build instructions]([url]https://github.com/obsproject/obs-studio/wiki/Install-Instructions#debian-based-build-directions[/url]), but I find it equally unlikely as anything else that there's a severe rm -rf / bug in there, and I'm not even sure that would cause symptoms to manifest in this way.

I at least still have my laptop from which I'm writing this, and my roommate has a rescue live disk that's currently plugged in, so I can mount my SSD and poke around according to suggestions, I just don't know what to look for. It is an LVM/luks encrypted FS but the rescue disk came with the suitable CLI utilities for me to decrypt and mount it anyways.

This is Debian 9 stretch=stable with Cinnamon GUI/wm. The root partition is separate from the home partition. Even the slightest suggestion of where to start looking for problems, nevermind how to fix it, would be most welcome. (I suppose worst case scenario I can reinstall the OS and overwrite the current root partition? I think the home partition is clean?)[/quote]

(This affects my aliquot reservation but not my NFS@Home work)

Of absolutely no value, but just to voice my opinion and that of the silent majority, the security and permission structure of Linux is an unnecessary pain. They keep making overriding these permissions more and more difficult to the point of being practically impossible. My Linux systems have 0 critical information and I wouldn't mind if the whole world had full access to them. Additionally having a secure open source software is an oxymoron.
I wished they would ease bypassing all those nonsensical permission stricture.

It's no different from Window's or any other multiuser OS

[QUOTE=a1call;485484]... I wouldn't mind if the whole world had full access to [my files].[/QUOTE]Until you are doing online ordering with your CC, or logging in to your bank/FB/email account. Then you will hope that no one can access your sessions keys.[QUOTE=a1call;485484]Additionally having a secure open source software is an oxymoron.[/QUOTE]Open source is actually part of the requirement for making sure it is secure. Closed source is harder to vet for security.

Did the disk just go "read only" due to I/O errors? This happened to me a few weeks ago on a 20 year old 40 GB HDD. :geek:

The disk is only a ~12 month old SSD. Plausible, but rather unlikely. I'm leaving memtest running overnight followed by Prime95 tomorow (memtest at 2h40m, no errors)

[QUOTE=Dubslow;485492]The disk is only a ~12 month old SSD. Plausible, but rather unlikely. I'm leaving memtest running overnight followed by Prime95 tomorow (memtest at 2h40m, no errors)[/QUOTE]

It will only go read only temporarily. You should check the logs to diagnose the cause.

[QUOTE=paulunderwood;485493]It will only go read only temporarily. You should check the logs to diagnose the cause.[/QUOTE]

Interesting :smile: where or under what title may ssd logs be found?

I can't quite remember. Probably one of the kernel logs.

[QUOTE=paulunderwood;485500]I can't quite remember. Probably one of the kernel logs.[/QUOTE]

Ah. Your prior post had triggered my memory that, though I tried to read the logs natively, I utterly neglected to attempt such from the recovery disk. Oops.

I'd have started with:
echo $PATH

Then ls -ld the various dirs in your path and see if the permissions look reasonable (they should usually all be readable and executable by everyone).

If you could still write to your home dir then saving output from various commands would be useful. Eg: [code]
env >> diag.txt
set >> diag.txt
mount >> diag.txt
df -h >> diag.txt
[/code] Ditto if you could ssh on to it from another systems that's working OK, you could save output there.

Next time you boot of the recovery disk try looking at permissions of dirs such as /usr/local/bin /usr/bin and /bin (this is where knowing what you path was when the problem started would be useful.

Also, have you tried to boot it back up without the recovery disk? It might have been a temporary glitch.

Chris