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

[jamieburchell]

Just updated my TS-212 to the latest QTS 4.3.3 with NFS 4 support but am unable to mount using nfs4 mount type.

Anyone got this working?

V3 still works, I noticed when I enable V4 it creates exports entries for /share/NSFv=4/... but that root directory is empty.

Tried restarting and turning on/off the services and resaving NFS share permissions.

Cheers

[jamieburchell]

Spoke too soon; after I rebooted the NFSv=4 folder was populated with my shares. Possible bug here somewhere me thinks.

[uazi335]

I also think there is a bug. I upgraded my TS-453A from the 4.2.5 (2017.04.13) to 4.3.3.
Since the upgrade my LibreELEC media players. can't browse for NFS-shares on this NAS. The shares don't show up. On my Macbook the command showmount -e ip-of-my-nas however shows the shares.
The NFS-shares on an old TS-219P+ that has been upgraded tot 4.3.3 however show up on the media-players.
When I downgraded the TS-453 back to 4.2.5 NFS was fully functional again.

[schumaku]

I also think there is a bug. I upgraded my TS-453A from the 4.2.5 (2017.04.13) to 4.3.3.

Had enabled NFSv4 before on 4.2.5 already?

Since the upgrade my LibreELEC media players. can't browse for NFS-shares on this NAS.

The media player has configured mount points? For NFSv3 or for NFSv4? As NFS does not allow "browsing" from the export root (because this is not a mount point) ... I'm a little bit lost what you want to tell us here, suspect this is unrelated to the technical NFSv4 folder the OP does talk about.

The NFS-shares on an old TS-219P+ that has been upgraded tot 4.3.3 however show up on the media-players.

The two previous poster state exactly the opposite - at least for the subject NFSv4, for the Marvell ARM model he is using.

On my Macbook the command showmount -e ip-of-my-nas however shows the shares.

There is a little oddity in QNAP's NFS implementation: A showmount does list _all_ shared folders configured, regardless if these are _really_ exported and available to mount.

When I downgraded the TS-453 back to 4.2.5 NFS was fully functional again.

Have you checked that 4.3.3 did properly show the NFS access rights on the shared folder management?

[uazi335]

Sorry, I misread the first posting. I have problems with NFS v2/v3 and its not related to v4. I will try to clarify my previous posting.

Had enabled NFSv4 before on 4.2.5 already?

There is no option available in the 4.2.5 configuration menu for v4. So the answer is no. It was always v2/v3.

The media player has configured mount points? For NFSv3 or for NFSv4? As NFS does not allow "browsing" from the export root (because this is not a mount point) ... I'm a little bit lost what you want to tell us here, suspect this is unrelated to the technical NFSv4 folder the OP does talk about.

What I tried to describe is that with NFS there is the ability to see all the shared folders on a NFS-servers with a NFS network browser. After upgrading to 4.3.3 my Macbook (with showmount -e) could still show me all the shared folders, while the LibreELEC mediaplayers just couldn't see the NAS when browsing the network for NFS. Another NAS, an old TS-219P+ also running on 4.3.3 with NFS, however did show up on the media player's NFS network browser.

In my situation I have 14 shared folders on the TS-453A and actually four of them are accessible through NFS. The TS-453A on version 4.3.3 however could still be accessed with the media player, when using previously set NFS-filepaths. So I could still play videos over NFS. However it wasn't possible to add new NFS-filepaths, as I have to add them through the NFS network browser. I had the problem with multiple players (which have been installed separately, they're not clones). When I downgraded the TS-453A to 4.2.5 all NFS functionality returned to normal.

Have you checked that 4.3.3 did properly show the NFS access rights on the shared folder management?

Yep, this panel looked perfectly normal. And it was still accessible as using NFS-filepaths that were configured when the NAS runned on 4.2.5 or older, still worked.

[mamfelt]

I had many problems with NFSv2/v3 (and now v4 on 4.2.5).
For the NFSv2/v3 issues I would recommend:
* stop NFS (/etc/init.d/nfs stop)
* make a copy of /etc/config/nfssetting (or move it to a new name)
* touch /etc/config/nfssetting (so it is zero bytes - nothing to export)
* start NFS (/etc/init.d/nfs start)

And now go back to the GUI and remake your exports.

Hint: You can also just run /sbin/gen_exports to see what you will be getting for /etc/exports

re: your NFGSv4 exports - could you post the output of mount? Thanks.

[dagroch]

Similar problem here, after an update to 4.3.3 some nfs shares were ok, some could not be mounted (permission denied). After enabling nfsv4 on the qnap all shares could be mounted again, no error or warning, but the shares previously not accessible were empty.

Changing the nfs access permissions from 192.168.1.* to the full ip without wildcard (e.g. 192.168.1.15) gave me back all my files. Changing the access permissions back to a wild card address I again get empty mounts.

When I now mount from a second client with a forbidden IP address (e.g. 192.168.1.16) then I also get an empty mount and no permission denied. I could be wrong, but this seemed to have changed with the update too.

Systems here are a TS-853A and a debian and ubuntu client.

[schumaku]

Changing the nfs access permissions from 192.168.1.* to the full ip without wildcard (e.g. 192.168.1.15) gave me back all my files.

Chair-keyboard problem: Wildcards were never (for decades...) allowed in NFS exports configurations for IP addresses, only in host/domain names. Results will be purely random.

[je_fro]

This - you cannot have asterisks in the "Edit Shared Folder Permission" form.
Woohoo!!

[schumaku]

This - you cannot have asterisks in the "Edit Shared Folder Permission" form.

You use domain wildcards, ie. *.dc1.qnap.com - not for IP address and subnetworks.

[ricarva]

@schumaku
@uazi335

So, I have a very similar situation to uazi335's.

As was

My old NAS was a 219P+ running QTS 4.3.3. I had NFSv3 running for years, mainly to serve media to Kodi-based players.

On the players themselves I'd go into "Browse" -> "NFS Share", and a popup would come up with the "NFS root" of my NAS (nfs://192.168.1.1//). Clicking that entry in the GUI would then show me all available shares on the server. One detail that could be important: Kodi only supports NFS v3.

With media shares setup this way, I never had anything apart from flawless operation.

The problem at hand

A few days ago I switched to a 251A (on QTS 4.3.4 beta), and yesterday went about configuring this same component, but with mixed results.

I enabled NFS on que QNAP GUI (v2/v3 and v4) and "NFS host access" for all relevant shares by ticking the "Access right" box. "Allowed IP Address or Domain Name" already came with a "*" entry that provides read-only access to the shares, which serves my purpose.

Going into the media player at this point, and trying every possible way, NFS shares weren't accessible. They would not come up through the "Browse" dialog described above, nor would imputing the full NFS path directly work; going into the Kodi log showed "access denied" errors, so I figured something would be off with permissions.

I also recalled being somewhat stuck on my original go at setting things up on the 219P+, and that it was finally solved by unticking some option... If only I could remember what that option was, 5 years ago! Fumbling through the NAS GUI eventually got me there; it was "Enable Advanced Folder Permissions". It came disabled by default in the new NAS; I ticked the box, clicked apply and waited for it to do its thing. Afterwards tested with the player, and still no dice... Still, I seemed to remember that the other time around it was *disabling* the feature that got things going, so tried it and... partial success! I can now setup NFS shares from Kodi if I use the full NFS path.

Trying to browse the network for NFS servers in Kodi's GUI, however, does not: Kodi throws up a "GetDirectory(nfs://) failed" error.

If it helps, here are my exports on the 251A:

Code: Select all

"/share/CACHEDEV2_DATA/Backup" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4" *(no_subtree_check,no_root_squash,insecure,fsid=0)
"/share/NFSv=4/Backup" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Completed" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Completed" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Download" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Download" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Movies" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Movies" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Multimedia" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Multimedia" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Public" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Public" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV2_DATA/TV" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/TV" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)
"/share/CACHEDEV1_DATA/Web" *(ro,async,no_subtree_check,insecure,no_root_squash)
"/share/NFSv=4/Web" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash)

I'm thinking NFS v2/v3 isn't exporting a root (fsid=0)???

I no longer have the 219P+ with me to be able to compare, unfortunately.

Is there any way to get to the bottom of this?

[ricarva]

I also think there is a bug.

Did you get this figured out? Any luck in getting it working?

Also, if you still have the 219P+ on hand, could you get the output to cat /etc/exports? And on your 453 as well, if still on QTS 4.2.5?

Thans

[ricarva]

Quick update on this!

I've done some research and testing to validate it, and believe I have a hold on the problem.

It hasn't much to do with the NFS implementation. Kodi uses libnfs, which has the routines to take care of NFS server discovery; 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.

I can confirm that the problem has something to do with the QNAP's handling of these requests. Using a "rpcinfo -b" command from another machine (which does very much the same as libnfs) other devices in the network answer back fine, whatever the service that is requested. I've also validated that the broadcast is getting to the NAS's network interface, so it's *not* an issue with my network (simple, single LAN setup).

Can anybody give me any further clues?

[ricarva]

Also, another quick observation.

QTS 4.3 is when QNAP introduced Virtual Switch for supported models. uazi335 states not having a problem with a 219P+ on the new firmware, which coincidentally didn't get this feature.

[schumaku]

Different from SMB of FTP where we have an ability to mount/access/browse the share "root" and chdir to the effective shared folder, NFS(v2/v3) does not export the shared root to browse as a pseudo file-system (by design, not by implementation). Of course there are some alternate ways to discover NFSv3 exports by using showmount -e (querying the rpc portmapper, like libnfs does it). A pure file-system like browsing to the exports is not available.

When it comes to pure NFSv4, there is no way to discover the exported file systems. Some NFSv4 implementations provide a pseudo file-system in the "root" - however this is not a standards requirement.

In either case (NFSv3 or NFSv4), the mounts take place on the exported file system, which is always has to be a sub-folder of the root only.

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.