Did Samba Update wreck my performance?

Support & Help Requests
1

I have two disks attached to a computer that are mounted on my Ubuntu-MATE server via cifs. Samba (smbd) is the utility that manages these, and I have a root-level cron job that mounts them at boot time.

The last couple of days my entire system has slowed to a crawl when any disk activity is performed, such as viewing a video with jellyfin.

I checked for disk corruption, and a variety of checks with iostat and iotop, check htop and ran fsck on the remote computer. Everything checked out. Ultimately, I wound up disabling samba and the slowdown disappeared! Of course, my remote disks are now not available to me, but at least I seem to have isolated the problem.

But how did it happen? I've been running this setup for a long time without any problems -- oh sure, there's more latency when accessing an external disk, but it hasn't been really noticeable. All of a sudden, even running ls -l on a local volume would take minutes!

All I can think is that an update to Samba is the culprit. I managed to find the last update by issuing

zgrep -h "smb" /var/log/dpkg.log* | sort | tail -n 1

and saw

2025-10-16 12:25:39 status installed smbclient:amd64 2:4.15.13+dfsg-0ubuntu1.10

But that's more than a month ago! My problem began only recently (full disclosure: I was out of town for ten days, so it might have occurred without me noticing).

My thinking is to revert to the earlier release, but I'm not sure how to do that. And I'm not sure that's the best solution anyway.

If you've got some ideas, I'd love to hear them!

2

Ok. I'd propose to check for network degradation next. For example, using large ping packets. Say, about 10% of packet loss makes network virtually unusable for bulk data transfers.

1 Like
3

Thanks. The largest packet size usable in ping is 65507 bytes (IPv4) and I see no degradation using that value. It doesn't seem the network is the problem.

1 Like
4

can you post how you mount the drives via cifs ?

1 Like
5

Yes. I run a cron script as root:

@reboot /usr/bin/ mount -t cifs -o credentials=/etc/samba/creds,uid=1000,gid=1000 //192.168.1.99/WK_POKT /mnt/homestorage

I have another drive from the same source computer (192.168.1.99) that I do the same thing:

@reboot /usr/bin/ mount -t cifs -o credentials=/etc/samba/creds,uid=1000,gid=1000 //192.168.1.99/OWC\ HD /mnt/owc

I read that Samba has a cache option (cache=loose, cache=strict, cache=none) but each has its own potential issues, so I've not tried implementing it as a possible solution.

Since this only cropped up recently, I'm trying to determine the root cause before I start more monkeying around.

1 Like
6

I assume there is no space here, typo ?

/usr/bin/mount

I suggest you enclose the second mount in quotes (b/c of the space).

@reboot /usr/bin/mount -t cifs                    \ 
-o credentials=/etc/samba/creds,uid=1000,gid=1000 \ 
"//192.168.1.99/OWC HD" /mnt/owc`
1 Like
7

The space is intentional. At boot time, the crond facility has no PATH, so it must be told where the mount command is found. Thus, it tells the operation that the command is found in /usr/bin.

On further reading, this has been working, but cron ignores the path /usr/bin and just moves to the mount command. Since it's been working, I don't think it's the cause of the slowdown, but wanting to keep things tidy, I cleaned it up, anyway. :blush:

1 Like
8

A couple more ideas:

  • Do you use sar and perf utilities? It looks like they may be more informative than dedicated IO monitors.
  • Samba update could rewrite some configuration files and cifs versions/parameters for server and client parts could bring up some incompatibilities.
1 Like
9

After shutting down both my Ubuntu MATE server and the remote computer I'm using as a file server, I brought them both up again and now everything seems back to "normal." Yes, I have some latency when accessing files on the remote server, but that's always been the case. I may try implementing one (or more) of the cache=none/loose/strict options in the mount command, but that's for another day. Right now, my systems are back operating nominally.

I hate when things like this happen without explanation, and then just as magically, clear up again!

1 Like