26 Sep 2012
"No Directory" error on login, after upgrading to Scientific Linux 6.3
I recently had a hardware failure, and decided to take the opportunity to upgrade my aging home server from Ubuntu ‘Dapper Drake’ to Scientific Linux. The reasons for my move away from Ubuntu are an article unto themselves, but it boils down to what I see as an increasing contempt for existing users (and pointless pursuit of hypothetical tablet users – everybody wants to try their hand at being Apple these days, apparently unaware that the role has been filled), combined with – and this is significantly more important – the fact that I have been using RPM-based distros far more often at work than Debian/APT-based ones, despite the many advantages of the latter. Anyway, so I decided to switch the server to SL.
The actual migration process wasn’t pretty and involved a close call
with a failing hard drive which I won’t bore you with. The basic
process was to preserve the
/home partition while tossing everything
else. This wasn’t too hard, since SL uses the same Anaconda installer
as Fedora and many other distros. I just told it to use my root
/, my home partition as
And then I rebooted into my new machine. And seemingly everything broke.
The first hint was on login: I got a helpful message informing me that
my home directory (e.g.
/home/myusername) didn’t exist. Which was
interesting, because once logged in I could easily
cd to that
directory, which plainly did exist on the filesystem.
The next issue was with
ssh: although I could connect via ssh as my
normal user, it wasn’t possible to use public key auth, based on the
authorized_keys file in my home directory. It was as though the ssh
process wasn’t able to access my home directory…
As it turned out, the culprit was SELinux. Because the “source”
operating system that I was migrating from didn’t have SELinux
enabled, and the “destination” one did, there weren’t proper ‘security
contexts’ (extended attributes) on the files stored on
The solution was pretty trivial: I had to run
# restorecon -R -v
/home (note as root!), which took a few minutes, and then everything
worked as expected. This was something I only discovered after much
searching, on this forum posting regarding a Fedora 12
install. I’m noting it here in part so that perhaps other
people in the future can find it more easily. And because,
unfortunately, there are forums filled with people experiencing the
same problem and receiving terrible advice that they need to reformat
/home (in effect, throw away all their data) in order to upgrade or
Bottom line: if you are running into weird issues on login (console or SSH) after an upgrade from a non-SELinux distro to a SELinux-enabled one, try rebuilding the security context before taking any drastic steps.
This entry was converted from an older version of the site; if desired, it can be viewed in its original format.