NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS 4312X SMB shares intermittently hang/freeze
ReadyNAS 4312X, running firmware version 6.10.10. Disks are 6TB 7200rpm SATAs of WD and Toshiba make, respectively. Network connection is bond0 over eth4/eth5 (the two 10Gbps NICs), configured LAC...
Further information:
When the connection drops, it's down for five or ten seconds for all clients at the same time. If a client isn't actively trying to read or write to the share, they don't even notice.
Date and time are configured to time-sync to the DCs and match.
There are no other apps on the device; NFS and Rsync are enabled for support of some backup jobs, but almost completely unused.
Audit logs are turned on, but the information in them consists solely of the login/logoff which doesn't seem to correlate with the drops.
This network configuration has existed longer than the trouble with the dropping share has occurred, but might still somehow be relevant:
Bond0 is running subinterfaces for access segmentation and service control.
bond0: (native VLAN 6), IP address 192.168.6.X/255.255.255.0/192.168.6.1 DNS nas1.sec.domain.local
bond0.2: (trunk VLAN 2) IP address 192.168.2.X/255.255.255.0/192.168.2.1 DNS nas1.domain.local
bond0.7: (trunk VLAN 7) IP address 192.168.7.X/255.255.255.0/192.168.7.1 DNS nas1.dev.domain.local
SSH/HTTPS/etc. are access-list blocked at the switches for all but VLAN 6, and you can only reach that VLAN through a firewalled management portal.
Just wondering - is this happening when the client is starting to communicate with the NAS? Or does it appear to be happening mid-flight?
I know this is going to seem like a non-answer, but it's not: Yes to both, sort of.
Sometimes it happens in the middle of a large file. But the Python process I mention is processing literally tens of thousands of 2.5MB files, and when it breaks, it breaks for the next few seconds of attempts. It could be one driving the other, though -- because if I'm processing the tiny files while handling the large one, the large transfer will *also* fail.
Leading the witness, but this seems like some sort of load issue or service crash on the NAS, where the system just can't keep up with the demand... but there's nothing in the logs or iostat/vmstat/netstat output to support that; conversely, a network issue, where there's some sort of renegotiation on how to connect to it. Nothing in the logs on the switches is showing flapping, and no mention of service interruptions on the NAS logs --- but I will freely admit I might be missing where to look especially on the NAS.
EMF2 wrote:
But the Python process I mention is processing literally tens of thousands of 2.5MB files, and when it breaks, it breaks for the next few seconds of attempts.
There are some linux limits that might be kicking in. The max number of open files is 65536 - is there any chance that the script is leaving some open?
If you go into the share settings -> network access -> SMB -> advanced, you'll see a "Strict Sync" setting. You could try turning that on, and see if that resolves the issue. (Performance might slow down though).
The way the Python process works, it should be closing each one rapidly after processing (it's a "with open(filename, 'w') as f:" ). lsof shows numbers in the low 20,000 range.
Unfortunately, "Strict Sync" is already enabled for this particular share.
A couple of my users just raised my stress level when they lost connection to the share altogether at the same time -- had to reboot their machines to return it -- which leads me to more closely suspect the NAS has something going sideways.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
