Re: unable to mount nfs4 mount

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3005 bytes --]

On Mon, Dec 26 2016, daggs wrote:

> Greetings,
>
>> On Mon, Dec 26 2016, daggs wrote:
>> 
>> >> Can you strace mountd while you attempt a mount?
>> >> e.g.
>> >>   strace -o /tmp/trace -s 1000 -p 241
>> >> 
>> >> and send the /tmp/trace.
>> >> Also, after the attempt fails, run
>> >>  rpcdebug -m rpc -s cache
>> >>  grep . /proc/net/rpc/*/c*
>> >>  cat /proc/fs/nfsd/exports
>> >> 
>> >> and report the output.
>> >> 
>> > here:
>> >
>> > # cat /tmp/trace
>> > pselect6(1024, [3 4 5 7 8 9 10 11 12], NULL, NULL, NULL, NULL) = 1 (in [3])
>> > read(3, "nfsd 10.0.0.1\n", 32768)       = 14
>> > openat(AT_FDCWD, "/run/nfs/etab", O_RDONLY) = 14
>> > fstat(14, {st_mode=S_IFREG|0644, st_size=435, ...}) = 0
>> > close(14)                               = 0
>> > write(3, "nfsd 10.0.0.1 2079 10.0.0.0/24 \n", 32) = 32
>> 
>> This is weird.
>> Here mountd is telling nfsd that when a request comes from IP address
>> 10.0.0.1, it should look for export entries associated with the client
>> name "10.0.0.0/24", which is good.
>> However the expiry time for that information is "2079", which is back in
>> January 1970.
>> When mountd writes that number, it computes it as
>>    time(0) + DEFAULT_TTL
>> where DEFAULT_TTL is (30 * 60)
>> Which suggests time(0) is "279".
>> 
>> What is the current time on this system?
>> 
>> If it really was very early on Jan 1st 1970, it should work, however...
>> 
>> 
>> > pselect6(1024, [3 4 5 7 8 9 10 11 12], NULL, NULL, NULL, NULL <detached ...>
>> > # rpcdebug -m rpc -s cache
>> > rpc        cache
>> > # grep . /proc/net/rpc/*/c*
>> > /proc/net/rpc/auth.unix.gid/content:#uid cnt: gids...
>> > /proc/net/rpc/auth.unix.ip/channel:nfsd 10.0.0.1
>> > /proc/net/rpc/auth.unix.ip/channel:nfsd 10.0.0.1
>> > /proc/net/rpc/auth.unix.ip/content:#class IP domain
>> > /proc/net/rpc/auth.unix.ip/content:# expiry=2079 refcnt=1 flags=1
>> > /proc/net/rpc/auth.unix.ip/content:# nfsd 10.0.0.1 10.0.0.0/24
>> 
>> ...the fact that this line is commented out indicates that the entry in
>> the cache is already expired.  So the time must be after 2079.
>> 
>> Maybe the time is getting set from the network at an awkward time that
>> races with NFS service some how.
>> Can you find a way to run "exportfs -f" after the time has been set
>> correctly?
>> 
>> NeilBrown
>> 
>> 
>
> wait, I think I've seen this somewhere, does this feature needs rtc? this board doesn't have rtc component.
> for example, I cannot use openssh as ssh server because it needs rtc. I have to use dropbear.
> if so, this looks like it will affect nfsv3 mounts, am I right?

No, you shouldn't need an RTC.
You need the synchronize the clock with ntp or similar, else time stamps
on files will look wrong.
Though I think we fixed issues with wall-clock-time jumping in 2.6.37...

If you could try using "exportfs -f", and explain what does happen with
time - do you use ntp ?? - we might be able to make progress.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]