NFS stops working after updating to 4.2.2 on 251+

[hulster]

Hi,

I am really sorry to bother you with that issue which seems to be discussed so often, but none of the stuff I found/discussed so far SEEMS to provide me a solution. Maybe I am just blind.
My 251+ is quite new, but owned a 110 before. I had all shares I need properly working mounted on a Enigma2 box, but stops after doing the update today.
Things/hints I have found so far:

- I have created a new share
- I checked permissions and even set guest account to r/w (other are admin and everyone)
- Have restarted the nfs services by GUI (disable, enable)
- Did a reboot after, which changed nothing
- Check the /etc/exports which makes me wonder because only contain the std folder /Public, not the other std and not the ones I have created

"/share/CACHEDEV1_DATA/Public" *(rw,async,no_subtree_check,insecure,no_root_squash)

- In Filestation the all std and own created shares are visible and browsable and contain the stuff expected means what they have before

The error messages are:

mount -v -t nfs -o rw,nolock 192.168.178.202:/Test123 /mnt/SidsNAS
mount: 192.168.178.202:/Test123 failed, reason given by server: Permission denied
mount: mounting 192.168.178.202:/Test123 on /mnt/SidsNAS failed: Bad file descriptor

The first line shows nfs service is running at all, because it is different when off.
In the GUI of the Enigma2 box the shares are visible, but no error messages stored in /var/log/messages when failing, but assume will be the same. Tried a simple mount without autofs and additional links created.

Thx in advance

[OneCD]

- I checked permissions and even set guest account to r/w (other are admin and everyone)

This might need some expansion.

Goto Control Panel, Shared Folders, your required share name, then "Edit Shared Folder Permission".

For the dropdown menu "Select permission type", did you select "NFS host access"?

Did you tick the checkbox "Access right", and then enter the hostname or CIDR of your target device so that it can access the share?

[hulster]

For the dropdown menu "Select permission type", did you select "NFS host access"?

NO - and that was the issue.
BUT 4.2.2 seems to change the behavior for this. I got the 251+ with 4.2.1. I have created new shares and they worked from scratch. I have NEVER touched the NFS host access. It seems it has been set by std to "* r/w". Now it seems ONLY std share /Public got it the rights by std. Further now if you change anything on the config of a share will issue to reset the access rights.
I am not going to discuss what makes sense from a security behavior or not, but if a general behavior is going to change I expect to give a notice to the user during the upgrade process.
FURTHERMORE I would really appreciate if such changes will not affect existing configuration, which it does. I take that as a onetimer, as from my expercience with the 110 for the last years an upgrade is usually trustworthy. So QNAP can take this as a heads-up to keep an eye on this perpective in the future.

[OneCD]

FURTHERMORE I would really appreciate if such changes will not affect existing configuration, which it does. I take that as a onetimer, as from my expercience with the 110 for the last years an upgrade is usually trustworthy. So QNAP can take this as a heads-up to keep an eye on this perpective in the future.

Well, in all fairness, I've only ever used NFS and I've always had to configure the NFS host access settings when setting up a new share. I've not seen it lose or change these settings before. And I've applied (nearly) every firmware update in the last 5 years.

From your experience, I suspect that there may have been an issue with your initial configuration that was resolved after updating.

[mamfelt]

I have made extensive use of NFS - and stayed on QTS 3.8.1 for years because I could not upgrade even to 3.8.4. HOWEVER, earlier this year I made an attempt again, and am now working well on 4.2.5. The problem has to do with the program the format of /etc/config/nfssettings changed, and old settings are/were not correctly turned into a working /etc/exports.

From my ticket on this:

It has been a painful process, but the problem is - simply - the update from version 3.8.1 to 3.8.4 (or even to 3.8.2, but never tried that) (to a new Linux version?) includes a change in the syntax used in /etc/exports. The program /sbin/gen_exports was not coded properly to translate the old /etc/config/nfssetting values to appropriate values.

Even after I found the root cause - it took a long time to figure out what the correct syntax is. One error I made - and was accepted - prevented me from continuing with the Web Interface (aka GUI). Only after editing /etc/config/nfssetting - correcting the error, was I able to use the GUI again.

The new program creates (from) "nfssetting:/share/MD0_DATA/projects = 192.168.129.*,*.home.local" an entry such as:

Code: Select all

"/share/MD0_DATA/projects" 192.168.129.*(rw,async,no_subtree_check,insecure,no_root_squash)*.home.local(rw,async,no_subtree_check,insecure,no_root_squash)

I have adjusted my settings (no longer 192.168.129.* aka 192.168.129.0/24) and for this share the input is now:

"/etc/config/nfssetting:/share/MD0_DATA/projects = 192.168.129.64/28, 192.168.129.60/30, 192.168.129.72/31"

and the result is:

Code: Select all

"/share/MD0_DATA/projects" 192.168.129.64/28(rw,async,no_subtree_check,insecure,no_root_squash) 192.168.129.60/30(rw,async,no_subtree_check,insecure,no_root_squash) 192.168.129.72/31(rw,async,no_subtree_check,insecure,no_root_squash)

At a very simple level, the comma (,) needs to be followed by a space.

Anyway, the issue was never the NFS engine, but the way the exports file is generated from the nfssetting file created by the GUI. Obviously, when starting from scratch there are no errors "left over" to keep it NFS from working. But with the wrong input - the exports were never valid, so nothing - literally nothing - could ever mount.

Hope this helps. I am glad to have it behind me!

[schumaku]

The new program creates (from) "nfssetting:/share/MD0_DATA/projects = 192.168.129.*,*.home.local" an entry such as:

Hm, the 192.168.129.*,*.home.local must have been user provided, not generated from the Web UI input.

Worth noting that the 192.168.129.* would never have worked correct, the results would be almost random ... form "any" access to "no access" - different form SAMBA, iptables, ... wildcards can only be used on domain names, not on IP addresses.