Arch Linux

Description:

When using a Linux desktop client that uses file shares mounted on a SAMBA file server (linux not Windows), I have recently encountered a bug in which some applications like Libreoffice and PDFSam are extremely slow to open and save trivially sized files over a gigabit LAN connection. I have run these programs from the command line but they never produce error messages and the operations do eventually complete, it's just that the programs hang for a long period of time before the operation finishes. Even more bizarrely, the "export to PDF" function in LibreOffice works perfectly and produces an output PDF in a fraction of a second (as expected) even when saving the ODF version of the exact same document produces a long hang.

For reasons I do not know, other file operations including file browsing, basic copying, and opening even very large files using other applications like Okular and Gimp work perfectly fine.

I do not know the underlying cause but I have found a configuration that causes the bug to manifest: When two different mounts on the same SAMBA server are mounted simultaneously the bug manifests. The mounts are to completely different file paths with no overlapping file hierarchy between the two shares. When only one share is mounted, everything works fine. When both shares are mounted, the bugs crop up.

The CIFS shares are mounted via fstab using the ordinary CIFS kernel module and I am not using GVFS or any higher-layer software to access the shares. I am reporting the bug against the kernel for right now because more than one client program appears to hit this bug.

Additional info:
Linux package: 4.14.3-1 (official Arch version).
cifs-utils: 6.7-2
smbclient: 4.7.3-1

Here are my mount options from fstab. I have tried playing with nobrl, turning caching on and off, turning _netdev on and off,changing the CIFS protocol version, etc. but no options have made any difference whatsoever:

//server/share1 /mnt/share1 cifs rw,iocharset=utf8,noauto,_netdev,user,nobrl,vers=2.0 0 1
//server/share2 /mnt/share2 cifs rw,iocharset=utf8,noauto,_netdev,user,nobrl,vers=2.0 0 1


Steps to reproduce:

Mount two different shares from the same SAMBA server as a client to make the bug manifest.