Nfs export list not updating
He verified this by logging into the NFS server and listing the contents of the exported directory. This was a typical case of inconsistent caching of information by an NFS client.
This works flawless and has been working since ages. Maybe someone sees what I don't and knows why this fails on the new host C.Subsequent client accesses to the directory first validate the cached information, comparing the directory's cached modification time to the modification time reported by the server.A match in modification times indicates that the directory has not been modified since the last time the client read it, therefore it can safely use the cached data.Done Building dependency tree Reading state information...Done Note, selecting 'rpcbind' instead of 'portmap' The following extra packages will be installed: libevent1 libgssglue1 libnfsidmap2 librpcsecgss3 The following NEW packages will be installed: libevent1 libgssglue1 libnfsidmap2 librpcsecgss3 nfs-common 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. After this operation, 836k B of additional disk space will be used. Y : : : # # apt-get install nfs-server--no-install-recommends Reading package lists...On the other hand, if the modification times are different, the NFS client purges its cache, and issues a new NFS request to the server to obtain the updated directory contents and attributes.
Some non-Unix NFS servers are known for not updating the modification time of directories when files are removed, leading to directory caching problems.
It fails as it tries to connect via TCP directly to 2049 but the port isn't open. Using NFSv3 will result in a RPC program/version mismatch. Update: All three machines are on one LAN, on the same switch.
There is no firewall active on host C: [email protected]:~# iptables -vn L Chain INPUT (policy ACCEPT 17 packets, 1853 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 20 packets, 5611 bytes) pkts bytes target prot opt in out source destination actually makes it work. I noticed that host B (the working one) did use a version 2 MNT call, while host C resorted to a version 1 MNT call. Using the full IP address for the one problematic host solved my issue.
If an export name contains spaces it should be quoted using double quotes.
I have a problem mounting a NFS share that I can't solve that is driving me nuts. I tried to mount the same share from host A but get a permission denied error: The fact that it works between hosts A and B should be prove that the NFS export per se is working.
No whitespace is permitted between a client and its option list.