This is an automated archive made by the Lemmit Bot.
The original was posted on /r/selfhosted by /u/slowmotionrunner on 2025-02-10 16:52:28+00:00.
SMB (and Samba which I use interchangeably) can be a fickle mistress. Virtually everyone with a home NAS will end up using Samba at some point and tuning it for the best performance can be somewhat of a dark art. This is the story of how I found my performance problems were from the last place I would have thought to look. TLDR at the end.
Here is the context for our story:
- 2 Windows PCs, one is my primary desktop and the other is headless
- 1 PiKVM connected to the headless Windows PC
- 1 new DIY NAS using Samba (technically Proxmox with Samba in an LXC)
- 1 Gbit ethernet across all devices
- Tailscale
The initial excitement of setting up my new DIY NAS with its 4, 20 TB drives soon became an exercise in frustration trying to figure out what could be causing transfers to run so slow. I had previously been getting transfer speeds from the desktop Windows machine to the headless Windows machine of ~100 MB/s. This is fairly close to theoretical maximum if you do the conversion of Mbps to MB/s and allow for overhead. With the new NAS having same or better hardware than the headless Windows machine, I expected the same or better performance, but was dismayed to see I was getting only 20-30 MB/s on average.
I'll try to consolidate the numerous dead-ends I went down that took me the better part of my weekend:
- Was it the hardware? No, local testing on the NAS showed it working just fine.
- Was it the choice of Proxmox/LXC? No, tried different distros, containers, and every combination in-between.
- Was it slow for just my Desktop machine? No, because copying from headless Windows to NAS was slow just like Desktop Windows to NAS was; both Windows machines behaved the same.
- Was it the Samba configuration? No, I tried endless variations on
smb.conf for buffering, socket options, caching, etc.
- Was it ports or firewalls? No, no, no...
- etc.
I spent most of my time with #4 because I naturally assumed I must have configured the share incorrectly, but, the thing that really sent me down the wrong road was #3. When I tested from either Windows machine to the new NAS, they both had slow transfer speeds and so I incorrectly concluded the problem was with the target NAS, not the source Windows, but that is where I errored. As unlikely as it was, both Windows machines had the same problem.
It was while I was running tests on the connection from Windows to NAS that I got this output in Powershell:
PS> Test-NetConnection -ComputerName 192.168.6.10 -TraceRoute
ComputerName : 192.168.6.10
RemoteAddress : 192.168.6.10
InterfaceAlias : Tailscale
SourceAddress : 100.122.134.77
PingSucceeded : True
PingReplyDetails (RTT) : 22 ms
TraceRoute : 100.117.103.126
192.168.6.10
I'm embarrassed to say that even when I first saw this output, seeing "Tailscale" gave me pause, but it still took me another day to understand what I was seeing here.
I love Tailscale and have it installed on all of these devices -- except for the new NAS while I'm getting it stood-up. Like a lot of Tailscale users, one of the devices in my LAN is also configured with subnet routing enabled. In this case, the PiKVM has subnet routing enabled and that makes things convenient when not all my devices have Tailscale installed or support Tailscale, but I can still access them remotely like they are on the local network.
Based on my understanding of Tailscale, even though I have subnet routing enabled, I expected items on the same LAN to go over their LAN addresses when using their LAN addresses. Were that true, my Windows Desktop at 192.168.4.235 would go directly to the NAS at 192.168.6.10, but as you can see the connection is taking a detour through Tailscale using the Tailnet IP of the Windows machine 100.122.134.77, to hit the Tailnet IP of the PiKVM subnet router 100.117.103.126, before reaching its destination. In other words, what should have been:
192.168.4.235 -> 192.168.6.10 was actually using,- (
192.168.4.235) 100.122.134.77 -> 100.117.103.126 -> 192.168.6.10
To test the theory, I temporarily disabled Tailscale on the Windows Desktop and, success! I was getting 110 MB/s! Better even than I was hoping for over my Gb connection! And why was the headless Windows machine also having problems? The same reason. Both my Windows machines were routing LAN request through Tailscale. Running Test-NetConnection again with Tailscale disabled produced this direct connection:
Test-NetConnection -ComputerName 192.168.6.10 -TraceRoute
ComputerName : 192.168.6.10
RemoteAddress : 192.168.6.10
InterfaceAlias : Ethernet 3
SourceAddress : 192.168.4.235
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TraceRoute : 192.168.6.10
Now, it is entirely possible I have done something wrong with my Tailscale setup, but I don't think so. I have everything installed pretty vanilla with default settings. Again, this is not the way I was told Tailscale was supposed to work when all the devices are are the same LAN and subnet routing is enabled, but I could have misunderstood.
So how do we fix this?
- Some of my research suggests that you can pin the SMB connections from Windows to a specific interface adapter using a "constraint" (
New-SmbMultichannelConstraint ?) so I could probably do that and pin it to my physical ethernet adapter, but I now considered this a network/Tailscale problem and didn't want to solve it for just SMB.
- We could monkey with the route tables and/or interface metrics in Windows (
Set-NetIPInterface?) to prioritize the physical ethernet adapter first and the virtual Tailscale adapter second to always resolve LAN addresses on the physical adapter, but I don't know how that would affect Tailscale and/or subnet routing.
- Or, we could not accept Tailscale subnet routing on machines that don't need it.
I went with the last option. When setting up Tailscale on Linux, you have to explicitly accept subnet routes using tailscale up --accept-routes, but on Windows it is the default. That was another thing I was not aware of and had I known, I would have never enabled it. This Windows machine is in my LAN, I don't need Tailscale to worry about subnet routing for me when I'm already in the LAN subnet. In Windows this can be disabled by right-clicking the Tailscale tray icon and disabling Preferences -> Use Tailscale subnets. And that is the simple solution that took me all weekend to figure out: disable subnet routing on the machines that don't need it.
TL;DR: Ensure your SMB connections are going over the traceroute you expect. Tailscale subnet routing is enabled by default in Windows. When you are already in the same LAN exposed by your subnet router, my recommendation would be to not rely on Tailscale to intelligently figure that out and simply disable subnet routing when not needed.
