Page 6 of 7
Re: NFS service issues at NAS startup
Posted: 01 Dec 2020, 21:37
by TMroy
Would you like a remote session from our tech team?
Re: NFS service issues at NAS startup
Posted: 02 Dec 2020, 00:08
by macmpi
Yes, we can give it a shot to get that sorted-out.
Re: NFS service issues at NAS startup
Posted: 02 Dec 2020, 22:35
by TMroy
So please email to our tech team, tell them your story and ask for a remote session.
Re: NFS service issues at NAS startup
Posted: 07 Dec 2020, 02:10
by 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
, 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.
Re: NFS service issues at NAS startup
Posted: 07 Dec 2020, 02:33
by 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.
Re: NFS service issues at NAS startup
Posted: 07 Dec 2020, 03:17
by macmpi
...could also be old nfs-server /
nfs-utils version, as it seems a fix has been implemented. (please read from
start)
Re: NFS service issues at NAS startup
Posted: 09 Dec 2020, 23:07
by TMroy
macmpi wrote: ↑07 Dec 2020, 03:17
...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.
Re: NFS service issues at NAS startup
Posted: 10 Dec 2020, 01:08
by 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?
Re: NFS service issues at NAS startup
Posted: 10 Dec 2020, 11:49
by TMSupport
You can SSH access your TNAS as root directly, the login password is the same with admin’s.
Re: NFS service issues at NAS startup
Posted: 10 Dec 2020, 15:52
by 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...)