Hi, I tried today using glusterfs 3.1.1 for shared /home on a classic ldap/nfs-like setup. With a few workarounds, I achieved to start correctly a gnome session: 1- Mounting nfs with nolock option; 2- symlinking .gconf and .gconfd of users to /tmp/.gconf and /tmp/.gconfd. Without these tricks, user session get stuck immediately after entering username/password (any gnome components get loaded, empty screen). I don't see any specific error on any gluster logs, is this an expected behavior? .xsession-errors: /etc/gdm/Xsession: Beginning session setup... Setting IM through im-switch for locale=it_IT. Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default. gnome-session[1333]: WARNING: Application 'gnome-keyring-ssh.desktop' failed to register before timeout gnome-session[1333]: WARNING: Application 'gnome-keyring-pkcs11.desktop' failed to register before timeout gnome-session[1333]: WARNING: Application 'gnome-keyring-secrets.desktop' failed to register before timeout gnome-session[1333]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout Error setting value: No database available to save your configuration: Unable to store a value at key '/desktop/gno me/applications/window_manager/default', as the configuration server has no writable databases. There are some comm on causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn' t found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the s erver on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the sec ond was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks , remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORB it still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc . As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per h ome directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~ /.gconf (polkit-gnome-authentication-agent-1:1398): GLib-GObject-WARNING **: cannot register existing type `_PolkitError' (polkit-gnome-authentication-agent-1:1398): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed Thanks. -- Giovanni Toraldo http://gionn.net/
