ReadyNAS RN42200 hangs completely up during backup to RN31400

Hi, Stephen, no I never activated never via Rsync Password (on the share, under Rsync). Double-checked, not activated.

May a good try to fin more out via ssh/rsync....

---

Worli wrote:

Hi, Stephen, no I never activated never via Rsync Password (on the share, under Rsync). Double-checked, not activated.

 

---

Then you shouldn't need a username/password in the backup job at all.  Though it normally does no harm to include it anyway.

---

Worli wrote:

 

May a good try to fin more out via ssh/rsync....

---

When you try that, you will need to override the default behavior (which is to run rsync over ssh).  You to that by prepending "rsync:" to the remote path.

Still, I'd try the 127.0.0.1 tests first.  That will rule out the network, and it might also pinpoint one NAS that is misbehaving.

Stephen, fune, will do the 127.0.0.1 first.

Stephen, on both boxes the 127.0.0.1-test was successful. I Rsynced locally from Share Music to Share temp2. 15GB within a minimum of time.

---

Worli wrote:

Stephen, on both boxes the 127.0.0.1-test was successful. I Rsynced locally from Share Music to Share temp2. 15GB within a minimum of time.

---

That suggests there might be something going on with your network.  Anything on the path that might be blocking ports?  Are you using the standard ethernet MTU, or have you configured jumbo frames?

How comfortable are you with ssh?

Hi Stephen, since everything runs "internally" I do not block amything on my LAN. The MTU is set on both boxes to 9000.
Today I tried to manually (via SSH on the Target box) the shares from Soruce-Box. I tried via CIFS and alternatively via NFS:

1. Created a subdir /mnt/test
2. Mount via nfs (mount -t nfs Source-IP:/data/musik /mnt/test) failed with mount.nfs: access denied by server while mounting 192.168.1.20:/data/musik
3. Mount via CIFS (mount -t cifs -o user=nede,domain=NAS4-worli //Source-IP/musik /mnt/test) asked me correctly to Enter the Password for the user and finshed. But when I go to /mnt/test and do a "ls" nothing comes. After a couple of minutes I cancelled with Ctrl+C.

When I do same from my Debian Server (is on same Switch as the Target-Box) everything is working fine. NFS as well as CIFS. I didnt look into the NIC config of Debuan. But I am quite sure the  am not on Jumbo Frames with the MTU.

Will change this now back on the boxes to the default MTU and will try again.

---

Worli wrote:

 

Will change this now back on the boxes to the default MTU and will try again.

 

---

I agree that's the next step. 

---

Worli wrote:

Hi Stephen, I think the MTU size (at 9000) was the root cause! After changing it on both boxes back to 1500 and a reboot everything worked. I successfully tried via NFS, SMB and Rsync.

 

Wow, this is really absolutely unexpected.

 

---

Great!  If you want to probe further, you could re-enable the jumbo frames, and then probe the path MTU between the NAS with ping (using the option to block packet fragmentation).  My guess is that there's a switch on the path that doesn't support ethernet frames this large (though it might still support jumbo frames with a somewhat smaller MTU).

Or leave well enough alone.  Jumbo frames don't always help performance - the main benefit is that they reduce the packets-per-second processing in the ethernet clients, which can reduce their CPU load.  It doesn't matter much to the network itself - the overhead savings are inconsequential.

---

Worli wrote:

 

However, many thanks Stephen for your help 

 

---

I'm happy to help, and I'm glad you got it figured out.