ICEauthority can't be updated on nfs home directory

I am experiencing a very similar error running an Ubuntu 10.10 system using LDAP authentication and mounting home directories through NFS. The differences:
1. We always get the error ".ICEauthority could not be updated" (at every login) regardless of whether the .ICEauthority-c file exists or not.
2. Our permissions aren't set correctly (though this is likely due to a LDAP/NFS server communication issue (there are 2 different servers running that the machines must communicate with. One of them is the NFS server and the other is the LDAP server). So this may be an unrelated issue. Here is a sample ls -la of my home directory (NOTE - this isn't the entire contents of my home directory):

drwx------ 2 nobody nogroup 4096 2010-05-10 09:16 .gvfs
-rw------- 1 nobody nogroup 1177 2010-10-03 16:57 .history
-rw-r--r-- 1 nobody nogroup 0 2011-05-18 11:53 .ICEauthority-c
drwxr-xr-x 2 nobody nogroup 4096 2010-05-10 10:27 .icons
drwxr-xr-x 2 nobody nogroup 4096 2010-07-16 07:56 .idlerc
-rw-r--r-- 1 nobody nogroup 1976 2010-08-18 10:55 index.html
-rw-r--r-- 1 nobody nogroup 704 2010-08-05 16:20 iter_01a.cpp
drwxr-xr-x 3 nobody nogroup 4096 2010-05-14 15:27 .java
drwx------ 3 nobody nogroup 4096 2010-05-25 13:04 .kde
-rw------- 1 nobody nogroup 49 2011-05-13 12:45 .lesshst
drwxr-xr-x 11 nobody nogroup 4096 2010-08-03 18:39 Library
drwxr-xr-x 3 nobody nogroup 4096 2010-05-10 09:16 .local
-rw-r--r-- 1 nobody nogroup 298 2010-07-02 13:40 .login
drwxr-xr-x 13 nobody nogroup 4096 2010-06-25 13:27 .lyx
drwxr-xr-x 3 nobody nogroup 4096 2010-07-07 08:35 .m2

Everything is owned by nobody and nogroup (as it is set to be in the config files), though an odd thing is that I can still modify and remove files as needed in my home directory (I am not sure if the nobody/ nogroup combination allows for anyone to modify files).

One thing I do want to point out is that it doesn't matter whether or not I have the .ICE* files existing in my home directory, the error occurs regardless (I can even remove the .ICE* files from /var/lib/gdm/ and the error occurs).

Well, I think that this is a very different problem even though the same file is affected.

Perhaps, though this is just the first bug report I have found that has someone using NFS and getting the error. Everyone else seems to be just having problems with their computer and running GUI programs as root, so I thought I'd post and see if a solution came around that worked for my case as well.

Just wanted to update. A colleague and I were able to solve this issue. As it turns out it was being caused by improper setup of the NFS servers and clients. The guy who set everything up in the beginning set the clients up to use fstype nfsv4 but the servers were set up to work with nfsv3, so we just had to update the fstype in all out auto.* files and removed the "4" at the end of the fstype argument (this solved 2 of the 3 issues we were having). The third issue was being caused by one of the servers being set up incorrectly. It didn't have base export line (I don't have a better name for it and am not able to access it from home). Once we added the line to the /etc/exports file, updated the exports and restarted the nfs kernel server that issue was fixed.

In all, we have been able to solve all our ICEauthority issues and LDAP wasn't a cause of the problem.

I'm experiencing it the same way as with the original post. Every second login the user gets the error.
Whatever I tried so far by changing the exports on the server or modifying the mount on the client didn't solve the issue.

On Server, /etc/exports:
/export 192.168.42.0/24(rw,fsid=0,no_root_squash,sync,insecure,subtree_check)
/export/home 192.168.42.0/24(rw,no_root_squash,sync,insecure,subtree_check,nohide)
/export/home/users 192.168.42.0/24(rw,no_root_squash,sync,insecure,subtree_check,nohide)
/export/home/groups 192.168.42.0/24(rw,no_root_squash,sync,insecure,subtree_check,nohide)

On the Client, /etc/fstab:
myserver:/home /home nfs rw 0 2

On the Client, mount provides me as output:
myserver:/home on /home type nfs (rw,vers=4,addr=192.168.42.202,clientaddr=192.168.42.204)

My Server is running Lucid LTS (10.04) and was upgraded a while ago from Hardy LTS.
The Client is a fresh install running Natty (11.04)

The client configuration I did copy fom a Intrepid (8.10) which for years connected to the Hard/Lucid server without any issue.

Just one more.

When I as a workarround create a .gnomerc entry by:

echo "export ICEAUTHORITY=/tmp/.ICEauthority.$USER" >>$HOME/.gnomerc

relocating the ICEAUTHORITY to a local storage, problem disappears.

I have this bug, too. My clients home is mounted with autofs, users and mountpoints are from LDAP. Server is ubuntu 10.04 LTS NFS2/3 style (without kerberos), client is ubuntu 11.04.

Relocating ICEAUTHORITY does not help.
Since testing that i have a additional error message:

There is a problem with the configuration server. (/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256)

Plus when i start a terminal the pwd is "/", but $HOME is set correct.

I'm experiencing the same problem.

Making sure that .ICEauthority-c is present before login makes the problem disappear for me.

I'm seeing this in /var/log/syslog every time the ".ICEauthority could not be updated" error appears:

Aug 4 17:48:05 ltsp kernel: [ 250.488372] non-accessible hardlink creation was attempted by: gnome-session (fsuid 10001)

I had the same issue. In my case I got the "could not update ICEauthority" error message at every logon. After switching both the server (/etc/exports) and client (/etc/auto.net) to NFSv4 the error message dissappeared. Big thanks to James for the suggestion!

Dern's solution doesn't apply here. Still get the same error in a setup with NFSv4+autofs+LDAP.

According to the OP's forum link, this problem wasn't present on systems < 10.10.

Could it be a race condition where :ICEauthority is created before the home dir is fully mounted?

I don't think it's a race condition between access and mount. Same here without autofs, home gets mounted at boot time. Happens only when I switch to nfs4, vers 3 works fine.

Hmmm, sometimes this happens for me on Ubuntu 10.04. The NFS server is running Debian oldstable, mounts managed by autofs, nfsv3 in use, noacl. This leads me to believe that it's indeed most likely a race on access/mount.

I think #11 is unrelated to this bug, as it seems that he does have a misconfigured id mapper daemon just as #1...