many "issues" after update to 3.8.4 (from 3.8.1)

[mamfelt]

-- moving post from Belgium (BENULUX) forums to here - as no replies before). was http://forum.qnapclub.be/viewtopic.php?f=16&t=2139

The problems with WebDAV I "solved" however the problem with NFS seems to be unsolveable.

I have verified that time is within 60 seconds on all systems.

Hence: Now a much bigger problem. NFS is broken.

When I try and list a directory I get a response:

michael@x054:[/data]ls -l x053
ls: cannot open directory x053: Value too large to be stored in data type.

This is for every NFS mount - this had been working without any issue for a long time. So, now I am desperate - how to go back to 3.8.1 - 3.8.4 is broken as far as I am concerned. No clue how to fix this.

background: the NFS mount was "/mountpoint" as that is what the command "showmount -e QNAP_hostname" reported, even though internally it was /share/mountpoint (which is a symbolic link to the real location - /MD0_DATA/mountpoint/

michael@x054:[/data]mount /aixtools
mount: 1831-011 access denied for x053:/MD0_DATA/mountpoint
mount: 1831-008 giving up on:
x053:/MD0_DATA/mountpoint
The file access permissions do not allow the specified action.

michael@x054:[/data]mount -r x053:/share/mountpoint /mountpoint
michael@x054:[/data]ls -l /mountpoint
ls: cannot open directory /mountpoint: Value too large to be stored in data type.
michael@x054:[/data]

michael@x054:[/data]umount -f /mountpoint
forced unmount of /mountpoint
michael@x054:[/data]mount -r x053:/aixtools /mountpoint
michael@x054:[/data]ls -l /mountpoint
ls: cannot open directory /mountpoint: Value too large to be stored in data type.
michael@x054:[/data]

I use these exports for forums - that are broken. I had not noticed earlier (family emergency kept me offline until now).

So, quick fix - how do I go back to 3.8.1?

[schumaku]

Hello Michael,

Welcome to the QNAP NAS Community Forum!

Looks like IBM AIX ... does the mount default to use NFSv4 or NFSv3? Consider to force the mount using NFSv3, use the mount with more verbose information, and check the NAS console (Kernel output) for any related messages ([~] # dmesg)

Advanced folder permissions enabled on the NAS, so ACL (and locked down U**X protection masks) come into play?

Anything prohibiting the roll-back from 3.8.4 to 3.8.1? Afraid, no more 3.x NAS in production.

Regards,
-Kurt.

[mamfelt]

Ok - recap - 3.8.1 reinstalled and everything worked as expected again.

I would like to do a firmware update to something newer, but do not want to mess up my current disks.

What I am thinking is putting an empty disk into the system (removing the current disks) and using that to update the system.

Question: will the system still be updated after shutdown and install of the old disks - i.e., how much dependency is there on boot and the installed disks (e.g., services). Ideally, all the real info and services is/are coming from the "firmware", not from the first array that gets mounted.

Question: does the "latest" QNAP firmware support NFSv4? (That would be great!) (and by latest, I mean 4.1.X - I am not ready to test 4.2.anything).

Regards,
Michael

[schumaku]

Ok - recap - 3.8.1 reinstalled and everything worked as expected again.

Nobody does give a s**t about v3 builds - history, no more maintained.

I would like to do a firmware update to something newer, but do not want to mess up my current disks.

Inconsitencies are pre-programmed. Especially older NAS models don't' have enough Flash storage space to accommodate all the firmware and mebedded packeges. QPKG / App Center stuff is always fully stored on the HDD - figure.

What I am thinking is putting an empty disk into the system (removing the current disks) and using that to update the system.

Fine - build a new system and migrate your data over.

Question: will the system still be updated after shutdown and install of the old disks - i.e., how much dependency is there on boot and the installed disks (e.g., services). Ideally, all the real info and services is/are coming from the "firmware", not from the first array that gets mounted.

See above. Firmware installations and updates can only be done on a complete system, and requires the storage in place. Start to create 100% backups of your data if you have any concerns.

does the "latest" QNAP firmware support NFSv4?

Usage case? Exact requirements to the NFS v4.1 implementation please?

Hope you are aware that NFS - regardless of v3 or v4 does massively differ from how al other services are working when it comes to access control. Mixing typical NAS services with NFS does requires huge system integration effort - in general it does most likely causing issues - and not everything that would be nice is available today, or with QTS 4.2.

[mamfelt]

Just thought I would mention: finally got it working with QTS 4.2.4. The problem all along is that QNAP changed to format of the file used to generate the nfs export file. If only they had mentioned this back in 2014. And, while they were trying, nicely and regularly, to help when I was trying to update to 4.2.3 - this was self-discovery.

re: NFSv4: QNAP does not support it (yet). The embedded linux has hooks for it, but support does not seem to be in the kernel.

re: differences of access. I would disagree about massive differences. There are differences. When it comes to file sharing it comes down to how users are recognized and how the server component manages that. You can have a CIFS/SAMBA setup that just uses the underlying *nix credentials, or you can configure it so that files are owned by a daemon (NTFS like). The issues you mention could be an issue if you were sharing a share both as SAMBA and as NFS at the same time. My configuration tends to be exclusive - and when they are mixed only "admin" has access to the SAMBA shares.

In short, yes I am aware of application differences. I am even learning, unfortunately, that W7 and W10 looks at shares differently, and not all W10 systems see the world equally (i.e., I have two W10 systems that see the QNAP as a CIFS server, and one that does not). C'est la vie!

[schumaku]

Just thought I would mention: finally got it working with QTS 4.2.4. The problem all along is that QNAP changed to format of the file used to generate the nfs export file. If only they had mentioned this back in 2014. And, while they were trying, nicely and regularly, to help when I was trying to update to 4.2.3 - this was self-discovery.

AS mentioned in your other thread: For NFS export purpose, wildcards on IP addresses access control was never supported. Originally, on the old UI, there was a note that the data entered is not checked, and it has to match the exports file requirements.

re: NFSv4: QNAP does not support it (yet). The embedded linux has hooks for it, but support does not seem to be in the kernel.

Of course it was - simple mounts by NFSv4 were always possible and workable. And it is (like NFSv2/v3) implemented in the Kernel, not in user mode. However, it was never officially supported.

The issues you mention could be an issue if you were sharing a share both as SAMBA and as NFS at the same time. My configuration tends to be exclusive - and when they are mixed only "admin" has access to the SAMBA shares.

Deploying dedicated shared folders for NFS makes perfect sense. Even if using admin in SAMBA, issues can arise. The ownership, the U**x protection mask is controlled by the client side - whereas on SAMBA these things are set correct as required (owner, U""x protection mask). And when other protocols like FTP or AFP or Web Applications come into the game, things will go wrong.

I am even learning, unfortunately, that W7 and W10 looks at shares differently, and not all W10 systems see the world equally (i.e., I have two W10 systems that see the QNAP as a CIFS server, and one that does not).

All Windows 7/8/8.1/10 systems see the CIFS/Windows File Server world in the same way - permitting these are in the same Network Location (ie. private). In Public network, CIFS client and server services are disabled and fire-walled automatically.

C'est la vie!

Oui. However, for user facing systems, NFS is on the way out (or was never really an option).