30 second Delay to Copy FROM Synology NAS to Local PC - SMB Version Problems

[ianjamesvale]

 * Nemo version (nemo --version) : 4.0.6
 * Is issue with desktop or windowed nemo? : Both?
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...) : Mint 19.1
 * Graphics hardware *and* driver used : see specs at bottom of post
 * 32 or 64 bit : 64bit

Issue When trying to copy files FROM a Synology NAS (DS115j) TO my local laptop via Nemo, there is an approx. 30 second delay before each file copies (whether copying a single file or several files, whether in folders or not). This does not happen with cp in Terminal, or with Konqueror, which do not have delays. Copying files to the NAS seems to be fine, as does using rsync to sync to the NAS. I have not tested rsync from the NAS to the laptop.

This behaviour seemed to start in Mint 18.3 at some point but I can't say exactly when, but is still present in 19.1 with a full clean install. It was not present in 17.3, and I don't remember it being present in 18.2.

Note: a test with Thunar also revealed the same delay.

Steps to reproduce Set up a computer with Mint 19.1, connect to a NAS, try and copy files from NAS to computer.

Expected behaviour No delay before a file is copied.

Other information

~$ inxi -Fxz
System:
  Host: xxxxxx Kernel: 4.15.0-45-generic x86_64 bits: 64 compiler: gcc 
  v: 7.3.0 Desktop: Cinnamon 4.0.9 Distro: Linux Mint 19.1 Tessa 
  base: Ubuntu 18.04 bionic 
Machine:
  Type: Laptop System: Acer product: TravelMate P259-G2-M v: V1.19 
  serial: <filter> 
  Mobo: Acer model: Lyra_SK v: V1.19 serial: <filter> UEFI: Insyde v: 1.19 
  date: 11/23/2016 
Battery:
  ID-1: BAT1 charge: 17.3 Wh condition: 32.3/42.0 Wh (77%) 
  model: SIMPLO AS16A7K status: Discharging 
CPU:
  Topology: Dual Core model: Intel Core i5-7200U bits: 64 type: MT MCP 
  arch: Kaby Lake rev: 9 L2 cache: 3072 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 21696 
  Speed: 3033 MHz min/max: 400/3100 MHz Core speeds (MHz): 1: 500 2: 500 
  3: 509 4: 500 
Graphics:
  Device-1: Intel HD Graphics 620 vendor: Acer Incorporated ALI driver: i915 
  v: kernel bus ID: 00:02.0 
  Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1920x1080~75Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2) 
  v: 4.5 Mesa 18.2.2 direct render: Yes 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: Acer Incorporated ALI 
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
  Sound Server: ALSA v: k4.15.0-45-generic 
Network:
  Device-1: Intel Wireless 7265 driver: iwlwifi v: kernel port: 4040 
  bus ID: 02:00.0 
  IF: wlp2s0 state: up mac: <filter> 
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Acer Incorporated ALI driver: r8169 v: 2.3LK-NAPI port: 3000 
  bus ID: 03:00.1 
  IF: enp3s0f1 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:
  Local Storage: total: 232.89 GiB used: 63.87 GiB (27.4%) 
  ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
Partition:
  ID-1: / size: 194.27 GiB used: 60.92 GiB (31.4%) fs: ext4 dev: /dev/sda2 
  ID-2: swap-1 size: 34.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:
  System Temperatures: cpu: 35.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 238 Uptime: 8m Memory: 31.29 GiB used: 1.53 GiB (4.9%) 
  Init: systemd runlevel: 5 Compilers: gcc: 7.3.0 Shell: bash v: 4.4.19 
  inxi: 3.0.27 

[ianjamesvale]

Update: So, after a morning doing resets and reinstalls, it turns out that the basic 18.3 iso with Kernel 4.10.0-38 works fine for all copying to and from the server. Upgrading everything but the Linux kernel saw everything still copy OK. Upgrading to 4.15.0-45 caused the copy from server problem. However, I have not tested all kernels between 4.10.0-38 and 4.15.0-45, so the issue is very likely to have been introduced somewhere between 4.10.0-38 and 4.15.0-45.

I will be staying on 18.3 with 4.10.0-38 as long as I can, but I'm expecting problems as I'm fairly sure there were some applications that had trouble with this old kernel.

[ianjamesvale]

Reopened, as thinking about it, I realised that there is a problem in the Linux kernel that causes the original issue, so that kernel changes or file manager changes that could impact it need understanding and correcting.

[LinuxOnTheDesktop]

This bug is one of several that makes using network shares on Mint exceptionally hard.

[ianjamesvale]

Tested Kernel 4.15.0-47.50~16.04.1 today, the problem is still evident.

[ianjamesvale]

Tested kernel 4.15.0-76.86 today, and the 30 second delay seems to have gone when copying files from NAS to local PC. I have no idea which kernel since -47.50 fixed the problem, but this now seems to be fixed.

[ianjamesvale]

I've just tried to do a copy of files from NAS to PC today, after a reboot/hibernation, and it appears the 30 second delay is back, so unfortunately this issue is still not fixed :(

[ianjamesvale]

I am now slowly working my way up through kernels (one or two a day) to try and find the one where the issue first shows up. Unfortunately Linux Mint doesn't have all kernels available in the updater, so I can only install those that are there. I'm up to 4.13.0-16, and the delay isn't there yet. ISTR that it happens somewhere in the 4.13.x-x range, but we'll see.

[ianjamesvale]

OK, so I've found the 'gap' where the problem starts.

LM 18.3 has access to install only certain kernels via the Update Manager, so it's that list that I'm working from. The network 30 second delay first occurs in 4.15.0-13. The kernel version before that is 4.13.0-45. So somewhere between those two, something was changed that introduced the 30 second delay.

Interestingly I also found another issue, where hibernation started failing. It worked up to 4.13.0-21, then in the next available kernel, 4.13.0-25 it started failing. It started working again with 4.15.0-13.

Does anyone know how I can get verified LM 18.3 suitable kernels between 4.13.0-45 and 4.15.0-13? If I can get hold of them easily enough, I can see if I can narrow down that gap.

Ian J.

[ianjamesvale]

OK, a breakthrough.

After trying to find an alternative way to mount my NAS folders, I read that the SMB version was changed in 4.13 in Ubuntu from 1 to 2.1 to 3.2 (some kind of dynamic usage).

Now I had another issue that I haven't previously mentioned, which is that when trying to access the NAS folders via my Windows 7 virtual machine in VirtualBox while on 4.13.0-21, the editing of files became very slow, but this didn't happen with 4.10.0-38.

I mount my NAS folders using scripts, with cifs. So that means I'm using Samba. I read in another post that the SMB version can be specified when mounting, using "vers=x.y". I have added "vers=1.0" to my scripts, and all now seems to be working OK again, both in Linux Mint and in the Windows 7 virtual machine.

So the issue appears to be one of SMB version used.

For the record, the Synology DSM allows setting of SMB version min and max. Though it was set to max 3 and min 1, it obviously wasn't playing nice with kernels after 4.10. I haven't changed that setting in DSM, I've just specified that the mounts use SMB1 and all seems to be OK.

So any bug/fix probably needs to look at SMB as to where the problem lies.

I will be keeping an eye on this for the next few days, with PC shut downs and restarts, just to be sure it is actually 'fixed'.

[LinuxOnTheDesktop]

As of now - though probably the problem started some time ago - Nemo seems to suffer period stalls merely when (1) a network share that is offline was browser to recently or perhaps (2) when such a network share is bookmarked. That previous sentence is disjunctive beause I am unsure which of the two is the cause. The shares in question are accessed via e.g. typing 'smb://192.168.1.8/docs' in the address bar (and the underlying technology there involves 'gvfs' I think). My kernel: 5.5.12.

Cf. also, perhaps: #424; #2332.

[LinuxOnTheDesktop]

One idea in this thread is that the problem is in the kernel. Another is that it is in Samba. I find it doubtful that this is a kernel bug. Would a bug in the kernel that was fairly serious, and that would be widely-encountered, persist for this long?

Anyhow: if, in one way or another, the problem is upstream, then it would be helpful if that upstream problem could be tracked via a bug report. So, and presuming that the problem is with Samba rather than the kernel: is this Ubuntu tracker the place to look for, or perhaps file, a bug? Or this other Ubuntu tracker? Also: if someone running Mint files a bug at either of those places, will that person get dismissed on account of not running Ubuntu?

Also, can Nemo not mitigate the problem in any way? I note that the problem extends to simply opening network shares, in some circumstances (see #2071).

[leigh123linux]

@LinuxOnTheDesktop It's a known gvfs issue.

[LinuxOnTheDesktop]

@leigh123linux

Right. Thanks. So: is there an existing bug report we can track? And can Nemo mitigate the problem?

[OdinVex]

@leigh123linux

Right. Thanks. So: is there an existing bug report we can track? And can Nemo mitigate the problem?

There is already an issue reported for it, well over a decade ago. Nothing has been done about it, it is an upstream issue. I just use scripts to use cifs instead on my Cinnamon-based installations (Manjaro Cinnamon, Mint Cinnamon).

Edit: I would like to hope that Cinnamon would increase the buffer size at least in their compiles for gvfs-smb (upstream uses 64K, the SMB1 limit). Normally the can scale, but gvfs never implemented that, and it stays at a very limited value. Cifs has no issue.

Edit: I think a second version of the package with a buffer that can be specified (blocksize) might be a very nice temporary work-around for all samba users. I compiled the backend a few months ago and got near cifs speeds using much more appropriate block sizes, but I'm in an environment that I can force SMB3+ clients and servers.

[LinuxOnTheDesktop]

@OdinVex: thanks. But I think that I switched to gvfs, from cifs, to avoid similar problems. Dear me. Anyhow, I've been using gvfs for a while now and mainly it works well, though I do not do anything demanding with it.

[OdinVex]

@OdinVex: thanks. But I think that I switched to gvfs, from cifs, to avoid similar problems. Dear me. Anyhow, I've been using gvfs for a while now and mainly it works well, though I do not do anything demanding with it.

Fortunately, I have zero issues with cifs and that's why I switched to it. As long as the gvfs method works for your setup, good. :) I regularly transfer GBs of files (50GB+) and it stucks waiting on a 10GbE ~18 hours with gvfs vs minutes with cifs.