Cannot access /home with KDE4 or Gnome after install 11.1

After installing 11.1 I am no longer able to access my /home directory.
My home directory is /home/jerome. When I log in as jerome, I cannot open this directory. Konqueror and the other file manager will hang there forever…just spinning their wheels. The strange this is that I am able to access /home/jerome/xyz or any directory below the top level.
If I log in as root, I am able to access /home/jerome.
I am only having this problem with KDE4 and GNOME.
KDE3.5 works perfectly OK.
Has anyone seen this problem?

  • cjbrathw,

I assume something went wrong with the rights during installation.
Alt+Ctl+F1
Login as root
chmod -R jerome:users /home/jerome

HTH
Uwe

I hate to call out a moderator, but this is very dangerous advice. You don’t know for sure that aren’t any symlinks to / or under in /home/jerome, and if there are, bad things will happen.

A safer option would be to (as root) do an ls -l of /home. You should see something similar to the following:


loki:~ # ll /home
total 12
drwxr-xr-x 155 kenn users 8192 Dec 22 17:45 kenn
drwxr-x---   2 1200 users    6 Dec 22 17:58 susan
drwxrwxrwt   4 root root    78 Dec 21 07:32 vm

Note that where we’d expect ‘susan’ to be the owner of /home/susan. Using my example, if we inspect the contents of /home/susan we find:

loki:/home # ll /home/susan/
total 0
-rw-r--r-- 1 1200 root 0 Dec 22 18:00 bar
-rw-r--r-- 1 1200 root 0 Dec 22 18:00 baz
-rw-r--r-- 1 1200 root 0 Dec 22 18:00 foo
lrwxrwxrwx 1 root root 1 Dec 22 18:00 slash -> /

Here is a simplified case where buckesfeld’s advice will result in a broken system.

There are 2 safe ways to fix this problem. First, if all of the files in /home/susan (or /home/jerome) have a numeric UID as the owner (and it’s the same for the vast majority of them), then the easiest fix is to make sure that user is logged out, and as root, change the UID number in /etc/passwd

susan:x:1201:100:Susan:/home/susan:/bin/bash

In this case, simply changing 1201 to 1200 will fix the problem.

The other option is a 2 step process using the find command. First change directories, then files.

As root cd into /home

find jerome -type d -exec chown jerome:users {} \;

Then cd into /home/jerome

find * -type f -exec chown jerome:users {} \;

find/exec is very useful, and it’s always safer than chown/chmod -R, expecially when unknown symlinks may be involved.

I have the sam problem.
I have modivied the fstab entrie

acl,user_xattr 1 1
to "
defaults
" and this fix the problem.
I hope it was proper.

Thanks

Klemi

  • kdemello wrote, On 12/23/2008 12:16 AM:

> I hate to call out a moderator, but this is very dangerous advice. You
> don’t know for sure that aren’t any symlinks to / or under in
> /home/jerome, and if there are, bad things will happen.

You’re right, thanks for pointing this out!

Uwe

I would like to thank everyone for responding. I tried all of the solutions offered, and I was actually able to access my home directory for a short while. Then the problem returned.
Actually I think the problem has to do with the presence of “.gvfs” directory in the home directory. This directory seems somehow to be blocking access… not even the root user can access it.
I know that this .gvfs has something to do with a virtual file system for Gnome, but does anyone know why it should be causing such a problem? Even better, can anyone offer a solution? :slight_smile:

PS: Uwe, I think that was a brave thing to do.

Just to follow up on this… I found that the only way I could stop ´./gvfs´ from being created and access my /home directory was to go into YAST and remove all of the ´fuse´ packages. After rebooting my /home directory was accessible.
As far as I can tell, this problem has something to do with an incompatibility between ´gvfs´ and ´fuse´. There seems to be a kind of blaming game going on between these two camps as to who should solve the problem.
Since I am not using GNOME I don´t think ´gvfs´ is essential and I don´t intend using ´fuse´ before this problem is cleared up, I removed ´fuse´ from my system.