![]() |
|
|
#1 | |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
3·29·83 Posts |
Cross posting from reddit:
Quote:
Last fiddled with by Dubslow on 2018-04-17 at 03:21 |
|
|
|
|
|
|
#2 |
|
"Rashid Naimi"
Oct 2015
Remote to Here/There
3·5·137 Posts |
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. |
|
|
|
|
|
#3 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
722110 Posts |
It's no different from Window's or any other multiuser OS
|
|
|
|
|
|
#4 | |
|
Undefined
"The unspeakable one"
Jun 2006
My evil lair
22×1,549 Posts |
Quote:
|
|
|
|
|
|
|
#5 |
|
Sep 2002
Database er0rr
3,739 Posts |
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.
Last fiddled with by paulunderwood on 2018-04-17 at 06:36 |
|
|
|
|
|
#6 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
1C3516 Posts |
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)
|
|
|
|
|
|
#7 |
|
Sep 2002
Database er0rr
3,739 Posts |
|
|
|
|
|
|
#8 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
3·29·83 Posts |
|
|
|
|
|
|
#9 |
|
Sep 2002
Database er0rr
72338 Posts |
I can't quite remember. Probably one of the kernel logs.
|
|
|
|
|
|
#10 |
|
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88
160658 Posts |
|
|
|
|
|
|
#11 |
|
Sep 2009
2·1,039 Posts |
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 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 |
|
|
|
![]() |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| MFAKTC worktodo.txt permissions keep changing back | Rodrigo | GPU Computing | 16 | 2017-12-23 15:04 |
| Installation of GGNFS | LegionMammal978 | Msieve | 17 | 2017-01-20 19:49 |
| installation of OS trouble | wildrabbitt | Linux | 5 | 2015-12-22 16:51 |
| Permissions | rebirther | Forum Feedback | 39 | 2013-12-08 15:16 |
| Current versions of MISFIT utilities | swl551 | MISFIT | 0 | 2013-03-11 02:29 |