RC2 -> Release NFS Changes

[rmr]

Hi,
I'm having problems with the NFS changes from RC2 -> Release when I try to mount from macOS.

The first issue was that on my system all exports were marked "secure" (meaning, port has to be < 1024). Looking into the code, this is controlled by "allow_nonroot". However, there is no GUI checkbox that I could find and I had to midclt call nfs.update '{"allow_nonroot": true}'. Is that expected?

The second issue is I cannot mount NFS v3 shares since (I think) rpc.statd is not running. This is despite the fact that /etc/default/nfs-common says NEED_STATD=yes (oddly enough the rpc.idmapd is running, even though I thought I don't need it since this is not a KRB environment).

Trying to run systemctl start rpc-statd fails with "rpc-statd.service: Can't open PID file /run/rpc.statd.pid (yet?) after start: Operation not permitted" in the log file.
When I remove the "-N" argument from /etc/default/nfs-common STATDOPTS, rpc.statd does start and the v3 mount works. But I don't know enough about all of the NFS layers to say whether doing this is correct or not.

Thanks for any pointers!

 

[morganL]

There was a major change in NFS from RC2 to Release. It went rom using NFS-Ganesha to the linux kernel version of NFS to resolve some issues. I'd suggest you report a bug if you have a set-up you can replicate.

 

[unf0rg0tt3n]

Hi,
I'm having problems with the NFS changes from RC2 -> Release when I try to mount from macOS.

The first issue was that on my system all exports were marked "secure" (meaning, port has to be < 1024). Looking into the code, this is controlled by "allow_nonroot". However, there is no GUI checkbox that I could find and I had to midclt call nfs.update '{"allow_nonroot": true}'. Is that expected?

The second issue is I cannot mount NFS v3 shares since (I think) rpc.statd is not running. This is despite the fact that /etc/default/nfs-common says NEED_STATD=yes (oddly enough the rpc.idmapd is running, even though I thought I don't need it since this is not a KRB environment).

Trying to run systemctl start rpc-statd fails with "rpc-statd.service: Can't open PID file /run/rpc.statd.pid (yet?) after start: Operation not permitted" in the log file.
When I remove the "-N" argument from /etc/default/nfs-common STATDOPTS, rpc.statd does start and the v3 mount works. But I don't know enough about all of the NFS layers to say whether doing this is correct or not.

Thanks for any pointers!

Got it working yet?
Doesn't work for me either, did a rollback to RC2.

 

[rmr]

Yes,
1) midclt call nfs.update '{"allow_nonroot": true}'
2) Remove "-N" from statd_opts in /usr/lib/python3/dist-packages/middlewared/etc_files/default/nfs-common.mako (this will cause /etc/default/nfs-common to be generated with STATDOPTS without the "-N"). I'm not sure that's the preferred method but it works.

 

[BrianDMG]

I'm having similar issues with NFS with RC2 -> RELEASE. 5/6 of my shares still work as expected, but one share (which I've deleted and recreated) isn't respecting permissions. UID/GID 1000 is the owner of the files on the server, and the same UID/GID exists on the client, but when mounted on the client shows the owner as root with different permissions than exist on the truenas server. As I stated, the rest of my NFS shares are working completely as expected. There was no issue on RC2. I tried the method @rmr posted, and still no luck.

 

[unf0rg0tt3n]

Yes,
1) midclt call nfs.update '{"allow_nonroot": true}'
2) Remove "-N" from statd_opts in /usr/lib/python3/dist-packages/middlewared/etc_files/default/nfs-common.mako (this will cause /etc/default/nfs-common to be generated with STATDOPTS without the "-N"). I'm not sure that's the preferred method but it works.

Thanks! Is this a suggestion by the devs until they release an update or is this some smart issue solving? Because as far as I know, this isn't mentioned in the release notes

 

[morganL]

I think this bug reflects the issue

https://jira.ixsystems.com/browse/NAS-115049

 

[MurtaghsNAS]

I am confirming similar issues. I haven't properly quantified the bug, but when I updated to Release, my NFS shares fell apart. Here are my observations:

1) I think the fix causing the problem is where we need to be once it is fixed proper. I'm a bit miffed the change happened so late in beta, but I admit it is better the correct solution ships, even if it is a bit rough right now.
2) A solution that might help someone is in previous builds I had constructed shares Alpha and Beta with the following structure:

• mnt
  • Alpha
    • Beta
    • Charlie
  • Delta
    • Echo

I had maps to /mnt/Alpha, /mnt/Alpha/Beta, and /mnt/Alpha/Charlie. Things were completely broken until I turned off access to the parent share of /mnt/Alpha. When I had removed any shares that had overlapping scope, I was able to access all my shares from multiple Ubuntu machines.
3) I did have to do some reconstruction on my shares. I had been a bit surprised when I had been able to create NFS directories from the client side. In the above example, I created the directory Charlie from a Ubuntu Machine, and then shared it through the Truenas UI. With Release, these were broken. I went into the shell, and renamed my existing Charlie to BadCharlie, recreated the Charlie dataset through the Truenas UI, then through the shell mv BadCharlie/* Charlie/. I also had a chown to do for my uses.
4) I still am having trouble, but I suspect it is a different aspect the bug. I think there are issues with anonymous NFS. An easy test bed is using Kodi Media Server.

• Test setup:
  • Create NFS Share on Truenas.
  • Put Video File on NFS share
  • On Kodi Machine, Create a video share
    • Go to Settings>System>Media>Libray>Videoes>Add Videos> nfs://hostname/mnt/Share
    • Select Ok.
    • Failure is a Dialog box "Unable to Connect" Yadda Yadda.
  • If you can play the uploaded video, it is success.

 

[AlexDRL]

Having some issues around NFS in that aspect too, now I can mount my shares but there is some issue with the user mapping, now all of them are recognized as nobody.
Are you sure that having this major change from RC2 to RELEASE is the best time for it?
I needed to rollback to RELEASE until this is properly fixed, or correctly explained at least.