NFS service issues at NAS startup

[TMroy]

Would you like a remote session from our tech team?

[macmpi]

Yes, we can give it a shot to get that sorted-out.

[TMroy]

So please email to our tech team, tell them your story and ask for a remote session.

[macmpi]

Just to clarify, NFS service is now started at NAS boot, but not in a way that works.
On client machine:

Code: Select all

showmount -e mynas.local
Exports list on mynas.local:
/mnt/md0/Recordings                 *
/mnt/md0/public                     *
/mnt/md0/Multimedia                 Everyone

When I try to connect after a fresh NAS Reboot, here is what I get on NAS console monitoring messages:

Code: Select all

tail -f /var/log/messages
Dec  6 18:54:45 TNAS daemon.notice rpc.mountd[6462]: authenticated mount request from 192.168.19.23:1017 for /mnt/md0/Multimedia (/mnt/md0/Multimedia)
Dec  6 18:54:45 TNAS daemon.warn rpc.mountd[6462]: getfh failed: Function not implemented
Dec  6 18:54:45 TNAS daemon.notice rpc.mountd[6462]: authenticated mount request from 192.168.19.23:1018 for /mnt/md0/Multimedia (/mnt/md0/Multimedia)
Dec  6 18:54:45 TNAS daemon.warn rpc.mountd[6462]: getfh failed: Function not implemented

Now, if I manually restart NFS service, here is what I get on client (notice the subtle diffence):

Code: Select all

showmount -e mynas.local
Exports list on mynas.local
/mnt/md0/Recordings                 *
/mnt/md0/Multimedia                 *
/mnt/md0/public                     *

and on NAS as mount is now successful:

Code: Select all

Dec  6 19:05:17 TNAS daemon.notice rpc.mountd[21350]: authenticated mount request from 192.168.19.23:1016 for /mnt/md0/Multimedia (/mnt/md0/Multimedia)

The difference in showmont shows that for some unknown reason, NFS service is not properly setup in some way at NAS startup.

[macmpi]

Looking around I found some similar issues on Drobo devices: it very much seem to be a NAS startup sequence issue, which may be different across systems and users, depending on config and apps installed... So may work in your end, but not at some customers'.
Some service scheduling dependency may not be explicitly ensured.

In Drobo case, the fix is to make sure that /proc/fs/nfsd is mounted before mountd starts.
Unsure is same in our case, but I think you get the point...
Thanks to have your engineers look into this closely.

[macmpi]

...could also be old nfs-server / nfs-utils version, as it seems a fix has been implemented. (please read from start)

[TMroy]

...could also be old nfs-server / nfs-utils version, as it seems a fix has been implemented. (please read from start)

We are verifying the issue you have reported, will come back to you soon.

[macmpi]

Thanks.
Support provided me with an updated /etc/init.d/nfs startup script, but I could not test it yet, because it seems that with 4.2.06 we can not get root privilege anymore:

Code: Select all

admin@myNas:/etc/init.d$ su -
Password:
setgid: Operation not permitted

While it may be a good security measure overall, it does not allow to tweak critical things anymore.
Is that intended?

[TMSupport]

You can SSH access your TNAS as root directly, the login password is the same with admin’s.

[macmpi]

I have tried the updated nfs startup script provided by mail, and it seems to resolve the issue: thanks!
Will it be included in next releases?

(maybe that script could be improved further by really testing nfsd daemon is indeed started before starting mountd: for exemple it could check if /proc/fs/nfsd is mounted. Currently it just assumes everything went fine. In my case it did, but maybe in some circumstances it may fail...)