NFSv4 on QTS 4.3.3 - /share/NFSv=4 empty?

[ricarva]

Querying the legacy QTS 4.3.3 as well as current NAS QTS 4.3.4 Beta portmapper and nfsv3 (and v4) mounts works for me from various U**x-like systems.

Thanks for the feedback, schumaku.

To be clear: portmapper on the QNAP responds to direct (i.e, to its IP) queries just fine. It's just the "rpcinfo -b" commands that aren't getting any replies from the NAS, although I can see the UDP broadcast packets reaching its network interface.

[schumaku]

portmapper on the QNAP responds to direct (i.e, to its IP) queries just fine. It's just the "rpcinfo -b" commands that aren't getting any replies from the NAS

Yes, indeed - I see replies only by the QTS 4.3.3 Marvell Kirkwood systems, the TS-x59/39 on QTS 4.2.x, ... and a TS-231+ (QTS 4.3.4 Beta with the Virtual Switch) - the x86_64 systems don't answer here, too.
Testing with this fwiw:

$ rpcinfo -b 10000 3
...

-> https://helpdesk.qnap.com/

Please add a reference to MantisBT ID 26638 (I've filed a bug report on this already, too).

Regards,
-Kurt

[ricarva]

Please add a reference to MantisBT ID 26638 (I've filed a bug report on this already, too).

Thanks for the debugging and confirmation, schumaku.

I'd already opened a ticket with QNAP on November 12th; I'll send you reference to the tech assigned to my ticket.

Cheers,

Ricardo

[ricarva]

Just a quick update: QNAP still hasn't gotten back to me on this ticket.

'Probably giving them a hard time to track down the issue.

Cheers,

[halol]

Difficult to know if this is related or not. But following the last firmware upgrade (now on 4.3.3.0396, with NFS 2/3/4 enabled), all my NFS shares but one were empty. Everything was working fine just before the upgrade, and I didn't make any change.
And there is no difference between the one share that still worked and those that did not. I rebooted the NFS client, unmounted and remounted the shares several times with always the same result: no error, just empty shares.

Simply executing the following commands solved my problem:

Code: Select all

/etc/init.d/nfs stop
/sbin/gen_exports
/etc/init.d/nfs start

But I haven't checked yet if this will survive the next reboot...

[ricarva]

Not sure how this would be related.

As an update for the original issue: QNAP acknowledged it as a bug and committed, via their tech rep, to address it in a future firmware update. I'll test and see if it was resolved with the latest beta.

[schumaku]

But following the last firmware upgrade (now on 4.3.3.0396, with NFS 2/3/4 enabled), all my NFS shares but one were empty.

Reads to me like the system required /etc/exports is not properly propagated during system boot - but correctly updated using /sbin/gen_exports ... as they said, certainly a bug.

[schumaku]

As an update for the original issue: QNAP acknowledged it as a bug and committed, via their tech rep, to address it in a future firmware update. I'll test and see if it was resolved with the latest beta.

Yes, looks much better now again on QTS 4.3.3.0396 (tested against some Marvell Kirkwood systems) and the current QTS 4.3.4.0411 Beta. The RPC info is correctly on the network. And yes, also the /share/NFSv4/ folder is re-populated again, too. Great discovery - thank you!

[ricarva]

As an update for the original issue: QNAP acknowledged it as a bug and committed, via their tech rep, to address it in a future firmware update. I'll test and see if it was resolved with the latest beta.

Yes, looks much better now again on QTS 4.3.3.0396 (tested against some Marvell Kirkwood systems) and the current QTS 4.3.4.0411 Beta. The RPC info is correctly on the network. And yes, also the /share/NFSv4/ folder is re-populated again, too. Great discovery - thank you!

You're quite welcome, sir

[alvoryx]

As an update for the original issue: QNAP acknowledged it as a bug and committed, via their tech rep, to address it in a future firmware update. I'll test and see if it was resolved with the latest beta.

Yes, looks much better now again on QTS 4.3.3.0396 (tested against some Marvell Kirkwood systems) and the current QTS 4.3.4.0411 Beta. The RPC info is correctly on the network. And yes, also the /share/NFSv4/ folder is re-populated again, too. Great discovery - thank you!

You're quite welcome, sir

Hi there

I have the same issue. As I didn't see this thread, I created another one viewtopic.php?f=35&t=138185&p=652236#p652236 a few days ago.

For me the issue is still there on the release 4.3.3.0404, is it also your case ?

Something else, I saw from your exports that you are using NFSv4. I don't get how this is working. For me, at the moment I enable NFSv4 on the QNAP (with NFSv2/v3 also enabled), Kodi is not able to mount any export. Kodi+NFS is only working if i have NFSv2/v3 enabled and NFSv4 disabled on the QNAP.

Also, you may have noticed, but using the "nfs browse" function of kodi actually "locks out" that specific kodi client out from the qnap, if you try from another kodi client it works. The only way to "unlock" the locked kodi client is to restart nfsd.

Finally, in order to correct what someone else said before, starting from a clean situation (nfsd restarted), the manual addition of a new export or the use of an existing nfs export in Kodi perfectly works : it is not very intuitive but instead of selecting "browse" on the related window, you just have to write down the nfs export, e.g. : nfs://192.168.1.1/Videos/


At the end it is not a big deal since what I just described works but still... I hate usefull things like those which stops working without any obvious reason. Thanks for your troubleshooting it saved me some time

[halol]

Quick update: I still have the same problem on the latest firmware as well (4.3.4.0427). After rebooting the NAS, my NFS shares are all empty until I restart nfsd. Contrary to my initial assumption I don't need to run gen_export again, a simple restart of the daemon is enough.
NB: I have an encrypted volume, this could explain the problem. I suspect that nfsd is not restarted after I unlock the volume. This used to work but somehow got broken after upgrading to 4.3.3.0396.

[alvoryx]

Quick update: I still have the same problem on the latest firmware as well (4.3.4.0427). After rebooting the NAS, my NFS shares are all empty until I restart nfsd. Contrary to my initial assumption I don't need to run gen_export again, a simple restart of the daemon is enough.
NB: I have an encrypted volume, this could explain the problem. I suspect that nfsd is not restarted after I unlock the volume. This used to work but somehow got broken after upgrading to 4.3.3.0396.

I believe we are talking about 2 different problems here.

You are facing another issue. In my situation after a reboot all my exports are working. It is this client broadcast part when trying to browse from Kodi which is causing the qnap to lock out that nfs client from any further connections until nfsd is restarted :

as per libnfs' developer, the way this is achieved is by broadcasting a UDP portmapper request for the required service and listening to which IPs answer back

If I was you, of course if possible, I would try to factory the device as it would avoid you searching around for nothing.

[alvoryx]

I just factory reseted my NAS (Reinitialize NAS option), the firmware which was automatically downloaded is the 4.3.3.0299.

Guess what ? nfs browsing is perfectly working on that release Which means, as I was telling, that the 4.3.3.0404 (or any firmware between) actually introduced the bug.

Now, before I start importing my stuff back into the nas, to be 100% sure the issue was not coming from any mistake, I will try to update my clean install to 4.3.3.0404 and let you know the results. But I can already tell you that I will have to start from scratch again and go back to 4.3.3.0299

Edit : Btw, now that I took the time to read them, in 4.3.3.0404 release notes :

[Other Changes]
QNAP will no longer release firmware updates for the following models after December 31, 2017.
TS-421U, TS-420U, TS-412U, TS-419U II, TS-419U+, TS-419U, TS-420-D, HS-210, HS-210-Onkyo, HS-210-D, TS-421, TS-221, TS-121, TS-420, TS-220, TS-120, TS-419P II, TS-219P II, TS-119P II, TS-212-E, TS-212P, TS-412, TS-212, TS-112, TS-419P+, TS-219P+, TS-119P+, TS-419P, TS-219P, TS-219, TS-119。

So this does mean that the bug introduced after 4.3.3.0299 will not be corrected on those devices updated to 4.3.3.0404 ?

[alvoryx]

I will try to update my clean install to 4.3.3.0404 and let you know the results. But I can already tell you that I will have to start from scratch again and go back to 4.3.3.0299

Guess what I am doing now ?

Bug confirmed on 4.3.3.0404

[schumaku]

So this does mean that the bug introduced after 4.3.3.0299 will not be corrected on those devices updated to 4.3.3.0404 ?

No. This means there won be any feature, functionality, and code updates. Technical Support (including bug fixing), and Security Updates will remain available until December 2020. FMI: https://www.qnap.com/en/product/eol.php

Aside, I can reproduce the issue here, and have filed a bug report with QNAP.