That date error is very suspicious.
Yeah, windowsish solution indeed :-(
Run memtest before the install as a flaky dimm can cause these errors as well.
sounds like an Windows fix, please reinstall :=) But that is just what I decided needs to be done, I emailed the client and will head out to client tomorrow morning.
One strange thing I noticed by mistake is the dates on folders.
[root ltsp tmp]# ll /opt/
drwxr-xr-x. 5 root root 4096 Mar 17 1913 ltsp
LTSP was hardly thought of 1913. I tried to look in different logs but can't see any file errors. But I see some folders being dated to 1913. Should matter for NFS, but if filesystem is that messed up no wonder NFS doesn't work.
I saw a blurb on a Ubuntu page where there was a kernel bug related to ext4 filesystem shared out by NFS. However, even though it showed the same error, it was still mountable from a remote machine.
I have a vanilla CentOS 6.4 with kernel 2.6.32-358 I tested the NFS server on with no issues.
disables NFSv4 in /etc/sysconfig/nfs
turned off iptables for the test
actually have selinux in enforcing mode
mounted remotely with no issues or errors on starting nfs service.
At this point, I think there's a problem with the hard drive. The top level inode collections are screwed up and NFS can't "do it's thing" because it can't read the filesystem metadata.
I would run 'badblocks' on the drive and reinstall (lousy answer and bad sysadmin solution but short of running strace on everything it may be the fastest way to working) with a fresh drive format.
K12OSN mailing list
K12OSN redhat com
For more info see <http://www.k12os.org>