Made a mistake and cleared all directories and files in root. I have a root session open still and have created:

# ls -la
total 36 
dr-xr-x---.  2 root root  4096 Nov 24 11:09 .
dr-xr-xr-x. 22 root root  4096 Nov 16 14:23 ..
-rw-------   1 root root 12035 Nov 24 11:53 .bash_history
-rw-r--r--   1 root root    18 Nov 24 11:08 .bash_logout
-rw-r--r--   1 root root   184 Nov 24 11:06 .bash_profile
-rw-r--r--   1 root root   481 Nov 24 11:07 .bashrc
-rw-r--r--   1 root root   101 Nov 24 11:09 .cshrc

But when I try to login to "su -" from another user on a second putty session I get a segmentation fault. What could be causing this?

  • Probably, because you cannot invoke a new shell – fpmurphy Nov 24 '16 at 19:31
  • Removing files should never cause segmentation fault. So it seems quite possible there is something important about your system which you haven't told us. With more information available it would be possible to provide a better answer. – kasperd Nov 26 '16 at 17:26

Try to create blank user with home dir and copy everything from his hlme to /root. Check rights and ownership for dir and files twice.

  • 3
    No need to create a new user. You could just copy the files from /etc/skel instead. – kasperd Nov 26 '16 at 16:46
  • 1
    @kasperd That's the best answer here. – Spooler Nov 26 '16 at 16:51

Many systems have no important files in /root.

If you use sudo to perform administrative tasks, then /root/.bash_history would never be created in the first place, and the other files in your directory listing would most likely remain static at all times.

As such wiping /root is on the harmless end of the spectrum of destruction you can do to a Linux system.

Removing /root does not prevent logins using su and sudo. It does prevent direct login as root using ssh keys for authentication. But the error message in that case would be different.

So any segmentation fault error message is not caused by missing files. It can however be caused by corrupted files. However since the files on your listing are text files and not binaries, it is unlikely for corruption in those to trigger a segmentation fault.

Since .bashrc is executed by the shell you open and since it does have access to execute arbitrary code, it is in theory possible to put code in there to trigger a segmentation fault and log you out again. But that's not something which happens by accident.

Another possible explanation is that there is some code being used in the login process which is missing error handling and causing a segfault by trying to use a NULL pointer which it got from a library function to indicate a missing file. If you have found such a case you should file a bug report against the program segfaulting, and then recreate the file to mitigate the problem.

Recreating the files in /root can be done either by reinstalling the package which owns the files installed in /root by default or by copying from /etc/skel which is where newly created users otherwise get their initial files from.

  • As @Speeddymon said, it is likely that this was b/c of Selinux context of the files he created. For the sake of the root cause analysis and complete answer (as this is the real problem, your answer is just a solution to it without explaining the problem), I'd point it out in the best answer around that it might get fixed by simply doing a restorecon -R /root. – Florin Asăvoaie Nov 26 '16 at 18:05

You likely have SELinux in enforcing mode. You'll need to reboot into single user or possibly even from a rescue disk, and restore the SELinux context of the files and the /root directory.

The steps to do the above are easily found on Google.

Alternatively, after you boot from rescue disk, you can edit the file /etc/selinux/config (be sure to mount your root partition first!) to disable SELinux completely and then you shouldn't get the segfault anymore once you reboot back into your distribution.

Not the answer you're looking for? Browse other questions tagged or ask your own question.