[SOLVED] SAMBA: very slow transfers, stuttering streams

t0phr · 2016-02-29 19:36:11

Hey all,
I noticed the following problem: reads and writes, from and to samba shares are very slow. Transfer speeds used to be way above 50 MB/s and are now ~12MB/s. When trying to stream a HD video from the share with Kodi or a Macbook, the video stutters heavily. The 12MB/s per second suggest a Gigabit/Fast Ethernet problem, but I ruled this out by watching and downloading the same video with Plex, where playback was smooth and the download quick ~60MB/s. Then I tried to downgrade my samba packages, but since version 4.3.4-2 libsystemd.so is used instead of libsystemd-daemon.so etc. which results in smbd crashing during startup. In anticipation of more severe problems I did not try a downgrade of systemd. But I used docker and a samba image based on Debian which uses samba version 4.1.17-Debian. I bound the folder with the video, shared it, tested with Macbook and Kodi and Playback was smooth. Copying from the share worked at a speed of 80 MB/s.
A downgrade to samba 4.3.4-2 behaves like the most recent version 4.3.5-1, so there is obviously something wrong with samba 4.3.4-2 and 4.3.5-1. I looked at the client, smbd and localhost logs samba produces up to log level 7 and there were no identifiable errors. Also tail -f on those log files and watching my stutter videos resulted in no errors.

Does anyone else experience the same problems? Since I found nothing on the forums a bug that affects all of us seems unlikely though my smb.conf does nothing special at all:

[global]
  hosts allow = 192.168.1. 127. 10.8.
  
  # disable printing stuff
  load printers = no
  printing = bsd
  printcap name = /dev/null
  disable spoolss = yes
  
  # user per machine logs
  log file = /var/log/samba/log.%m

  # fix possibly buggy Windows clients
  reset on zero vc = yes
  # level 1-10, 1-3 recommended
  log level = 7

  security = user
  netbios name = SRV
  server string = srv
  unix extensions = no
  wide links = yes

  socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[Share]
  path = /srv/share
  valid users = user
  public = no
  writable = yes
  printable = no

Any ideas? If need be I will upload logs of any desired verbosity levels but since I'd need to filter out any private information I decided to do this upon request.

Last edited by t0phr (2016-03-03 22:18:32)

alphaniner · 2016-03-01 04:20:59

When samba derps, it's always a good idea to remove any non-default settings that aren't 100% necessary. In this case, I'd start with the socket options. They have as much potential for harm as for good. Disconnect any client-side mappings, make the changes, reload smbd (restart isn't necessary), then see if things change.*

For the record, I'm running 4.3.5-1 and connecting from Win 7. With no socket options configured (actually, TCP_NODELAY is default), speeds saturate my 1GB connection.

Also, instead of posting your smb.conf run testparm to see what your config boils down to. Consider running it before you make any changes.

* Client disconnection may not be strictly necessary, but IMO it's a good idea when doing this sort of troubleshooting.

Last edited by alphaniner (2016-03-01 04:26:33)

t0phr · 2016-03-03 22:15:22

Thanks a lot for your answer. I managed to sort out the problem, but I have no clue what fixed it.

I tried your suggestions. Without the socket options the result was the same, speed around 12MB/s. This is the config as output by testparm (after removing socket options):

# Global parameters
[global]
	server string = SRV
	security = USER
	log file = /var/log/samba/log.%m
	reset on zero vc = Yes
	unix extensions = No
	load printers = No
	printcap name = /dev/null
	disable spoolss = Yes
	idmap config * : backend = tdb
	hosts allow = 192.168.1. 127. 10.8.
	printing = bsd
	wide links = Yes


[Share]
	path = /srv/share
	valid users = user
	force user = other_user
	read only = No

Then I did the same on the docker container I mentioned, the testparm output was like this:

[global]
        server role = standalone server
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        syslog = 0
        log file = /dev/stdout
        max log size = 1000
        load printers = No
        printcap name = /dev/null
        disable spoolss = Yes
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb
        force user = smbuser
        force group = users
        force create mode = 0664
        directory mask = 0775
        force directory mode = 0775
        printing = bsd
        print command = lpr -r -P'%p' %s
        lpq command = lpq -P'%p'
        lprm command = lprm -P'%p' %j

[Share]
        path = /srv/share
        guest ok = Yes

While having the docker container running to get the testparm output I again verified the speed when copying, still 90MB/s. Since the configurations differ a bit I wondered if my new bleeding edge samba would be fast again when configured like the 4.1.17 samba in the docker container.
So I created a smb.conf with the testparm output from the docker container and did no further changes on the server except creating the user 'smbuser'. Then I started smbd 4.3.5.1 with that smb.conf, the speed was up at ~90MB/s. Now I switched back to my old smb.conf again, with the plan to find the nasty setting that was killing the speed by incrementally adding/changing the options to be like the containered samba's. So, I started smbd 4.3.5.1 with the problematic smb.conf, tested the speed a last time to verify the slowness and copy speed was up at ~90MB/s. I deleted the user 'smbuser' but speed was still up at 90MB/s. I have no idea what might have fixed it... Again, any ideas?

For reference, in the process of trying to fix this before posting here I did several reboots, switched between several kernels and kernel versions, downgraded and upgraded samba several times and modified the smb.conf (added the socket options, added/removed shares). So the plain old strategy of turning it off and on again does not explain this :D

Last edited by t0phr (2016-03-03 22:19:01)

alphaniner · 2016-03-03 22:23:25

Glad you solved it, though I'm genuinely surprised removing the socket options had no effect. I managed to get my speeds to drop from ~110 MB/s to ~60 MB/s by adding your socket options.

So the plain old strategy of turning it off and on again does not explain this

Blasphemy!

t0phr · 2016-03-03 22:48:37

Now I'm completely confused. I added the socket options back to my config, which causes the speed to drop to 12MB/s. So this looks very much like I'm the core of the problem , BUT in my defense, I know (as I git my configs) I added the socket options after the slow speeds occurred as I hoped it might fix the issue. The samba server was fast for months before. The speed drop happened after I did some updates, reorganized hard drives and turned on encryption, without me even touching smb.conf. Very, very weird...

To conclude this, TIL

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

works reliably when slow transfers and stuttering videos are what you need.

Last edited by t0phr (2016-03-03 22:48:56)

cam1900 · 2023-01-24 22:23:07

i confirm, editing and inserting in /etc/samba/smb-global.conf

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
instead
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=2048000 SO_SNDBUF=2048000

solve the problem.

now the transfer is 50 mbit/s instead 2 mbit/s

Many thanks to t0phr and alphaniner for the solution :-). Thanks guys.

Last edited by cam1900 (2023-01-24 22:28:50)

2ManyDogs · 2023-01-24 23:34:02

Closing this ancient solved thread.

Arch Linux

#1 2016-02-29 19:36:11

[SOLVED] SAMBA: very slow transfers, stuttering streams

#2 2016-03-01 04:20:59

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

#3 2016-03-03 22:15:22

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

#4 2016-03-03 22:23:25

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

#5 2016-03-03 22:48:37

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

#6 2023-01-24 22:23:07

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

#7 2023-01-24 23:34:02

Re: [SOLVED] SAMBA: very slow transfers, stuttering streams

Board footer