Linux Mint Forums

Hi,

I've come up against a strange problem. I have a Synology NAS shared to my laptop running Mint 18.3. Until recently all file operations in the GUI worked to and from as expected over the network.

Now something has changed on the laptop (no changes have been applied to the Synology as it has no internet access) such that all file copying/moving TO the NAS run at expected speeds (for a 100Mbit NIC as in the Synology NAS), but all file copying FROM the NAS is painfully slow if it will work at all.

Strangely, if I listen to music files, view videos or browse photos directly in the GUI from the NAS, they load and run fine in their relevant applications. It just seems to be the copy operation from the NAS to the laptop that is having problems.

Any ideas what could have changed that is causing this problem?

TIA

Ian J.

Addendum:

Two additional pieces of information from a bit of testing:

1. VLC Media Player struggles to open and play an MP3 file that's on the NAS

2. Using CLI CP command, files/directories seem to copy as per normal.

I am currently summizing that the problem lies in the GUI somewhere, perhaps in Cinnamon's file manager?

Edit: an additional test reveals that the action to copy a file (whether a single one, or one of a batch), takes approximately 30 seconds of doing nothing, then the file copies at what seems to be normal speed. Additional files, if in a batch copy, then do the same each, 30 seconds doing nothing, then copying the file at what seems to be normal speed.

Update: I've just upgraded to 19.1, but this has not solved the problem, there's still a 30 second delay before a file actually copies.

Update: I installed Thunar to see if that was any different, but it has the same problem as Nemo (in Cinnamon), 30 second delay before copy of any file. I then installed Konqueror and that works OK.

So it appears there is a bug somewhere (maybe in Gnome?) that's causing the 30 second delay. How do I report a bug in Linux Mint?

I've got a DS216j and have no problems with it at all. Don't use it to play videos on my laptop but just tried it with the default media player and no problems. File copy in both directions is fine. It is connected to my laptop via a gigabit switch and was fine with the laptop wired or wireless (obviously slower). Running 19.0 cinnamon on my T430. I previously had a 10/100 switch and it was okay with that although, as expected, slower. The problem is not in mint, but sorry can't be more helpful and point at something specific.

Mine's a DS115j, and hasn't had any software changes since purchase. It used to copy back to the PC OK but something changed during my use of LM 18 to put the pause in, but not for all systems of copying so I can only assume it's a problem with something in LM, or something LM uses (as both Thunar and Nemo have the problem, but not the cp command in the terminal, nor Konqueror). It's the same in 19.1, so I have to assume a bug in there somewhere, so I'd like to report it.

Bug reported on Github under linuxmint nemo.

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.

Update:

After a long period of not bothering to test this problem, I've just updated 18.3 to kernel 4.15.0-76.86 and copying from the NAS to the local PC seems to be OK.

I spoke too soon. I've just tried to do a copy of files from NAS to PC today after a reboot/hibernation, and it's gone back to a 30 second delay between file copies.

Back to 4.10.0-38.

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.

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

LM 18.3 only has access to install 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.

You can use UKUU, but it does tend to get frowned on (you get the mainline kernel). I've used it in the past for a similar but different problem - ultrawide monitor was detected automatically in any kernel less than 4.5.7 but not thereafter. If you go for an earlier kernel make sure you choose an LTS version.

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'.