CIFS and NFS mounts intermittently dropping on new QNAP

[atomey]

I am in the process of migrating from TS-451 (8GB) to TS-435XEU (4GB) (rackmount).

Both are running same version of latest QTS and I was able to sync all my data with HBS via Shared Folders. I recently setup both NFS and Samba (CIFS) mounts in Debian. However when I try to mount either NFS or CIFS, the mount will become inaccessible intermittently with the new QNAP. Not sure what is wrong, it has 4 GB ram and resource utilization is low when it happens.


When using CIFS, this is the error that will show sometimes:

Code: Select all

: [82189.618492] CIFS: VFS: \\10.1.1.4 has not responded in 180 seconds. Reconnecting..

Similarly, if I mount with NFS (v4, also tried v2/3) I'll see this:

Code: Select all

kernel: [ 1286.691643] nfs: server 10.1.1.4 not responding, still trying

I'm using this as my fstab:
CIFS

Code: Select all

//10.1.1.4/multimedia  /mnt/multimedia          smb3 sec=ntlmv2,cred=/usr/local/etc/whisper.credentials,uid=1000

NFS

Code: Select all

10.1.1.4:/multimedia    /mnt/multimedia nfs     defaults        0       0

I never had this issue with the TS-451, which granted does have 8GB. I am considering adding 32GB ram to XEU to eliminate any bottlenecks but utilization is low. I am running multimedia software for streaming mostly so many files can be opened at any time.

This is a virtual VMware server running Debian 11 and it's connected through physical server (Supermicro intel Atom) via 10Gbe (same as the NAS). I don't believe it's a network issue I never see any network drops nor any resource utilization/choke issues (CPU/RAM).

I primarily upgraded to get 10Gbe and have a rackmount so hoping to resolve this without swapping out to another NAS since it works but it's unstable...

[FSC830]

"Same version of latest QTS" is not a suitable information. Tomorrow this is may be not any longer valid. Please provide always exact version information.
Just to still curiousity: you are mounting the same filesystem with both protocols to the host? To the same mountpoint? At the same time?

Why are you using cifs for a Debian host?
Disable nfs v4 at NAS and check again. At least the latest(?) Ubuntu (currently 22.04.01) has some issue when NAS has nfs v4 enabled.

Regards

[rakeller]

I am having the same issue with Ubuntu 22.10 connected via SMBv3.1.1 with my TS-435XEU, please see:

viewtopic.php?f=35&t=168586

The same problem also happened with NFS.

So far, I've tried different SMB versions, SMBv3.1.1, SMBv3, SMBv2 all hang intermittently. However, when mounting with SMBv1, then connections are stable (I am aware that SMBv1 is outdated).

I've tried to debug the traffic, it seems that the client and server get out of sync, and at some point SMB Echo requests fail (but they are not sent out on the wire).

[atomey]

"Same version of latest QTS" is not a suitable information. Tomorrow this is may be not any longer valid. Please provide always exact version information.
Just to still curiousity: you are mounting the same filesystem with both protocols to the host? To the same mountpoint? At the same time?

Why are you using cifs for a Debian host?
Disable nfs v4 at NAS and check again. At least the latest(?) Ubuntu (currently 22.04.01) has some issue when NAS has nfs v4 enabled.

Regards

Version is:
5.0.1.2194

No, only mounting one protocol. Originally on my TS-451 I used samba for years but eventually switched to NFS v2/3 due to very rare but occasional drops in connection.

Now I am using the same settings on the 435XEU and neither is stable. Also tried NFS V4. I get regular timeouts, for exampe most recent one:

Code: Select all

Nov 29 21:06:40 host kernel: [277670.317405] CIFS: VFS: \\10.1.1.4 has not responded in 180 seconds. Reconnecting

I confirmed I never get a ping drop and otherwise not noticing any other services degrading on the Debian box.

Nothing wrong with CIFS but again, I would use NFS but both have same issue with this particular NAS. I didn't update or change the Debian box so the NFS package/client should be fine. I'm sure Ubuntu would probably have similar issue so it's either some weird network issue or server issue which may be distinct to the ARM model perhaps...

Disabling NFS v4 did not help, 2/3 have same issue.

[atomey]

I am having the same issue with Ubuntu 22.10 connected via SMBv3.1.1 with my TS-435XEU, please see:

viewtopic.php?f=35&t=168586

The same problem also happened with NFS.

So far, I've tried different SMB versions, SMBv3.1.1, SMBv3, SMBv2 all hang intermittently. However, when mounting with SMBv1, then connections are stable (I am aware that SMBv1 is outdated).

I've tried to debug the traffic, it seems that the client and server get out of sync, and at some point SMB Echo requests fail (but they are not sent out on the wire).

Interesting since you have 435XEU too... I can only think that the architectural differences are the biggest difference since I have same config working on an Intel model. Same config/QTS version, no drops on Intel/x86 vs. ARM.

[rakeller]

Please also see this thread as I am also having stability issues with a MacBook Pro with the QNAP connected over 10Gbit using SMBv3.1.1:

viewtopic.php?f=30&t=168538

However, when connecting the MacBook Pro with a PC running Ubuntu 22.10 over 10Gbit with SMBv3.1.1, the connection is fully stable -- so it seems an issue with the QNAP.

[atomey]

I ended up switching to a Synology and migrating. I had similar timout issues when using HBS3 so I'm pretty sure the TS-435XEU is either a lemon or the software (more likely) is buggy and has a timeout issue in the Linux TCP stack somewhere.

I had to run the HBS3 job to sync back to my old QNAP many times before I was able to migrate to the Synology. Hopefully QNAP can resolve with the ticket I opened but I wouldn't buy the TS-435XEU until they fix it...

Let's see if this post lasts