Anyone else on Core 13.3 notice "delays" when connecting/reconnecting to SMB shares?

What I do in my private time is none of your business.

Besides, your ability to make clear, easy-to-understand tutorial videos about TrueNAS makes me suspicious about your humanity. :unamused:

If you must insist, then please prove you’re not a robot:

CLICK HERE, ONLY IF YOU SOLVED THE CAPTCHA
You cheated! But I can't stop you...

Unlike Linux (and Mac?), Windows does not let you change the user to connect to an SMB share. Whether you use a mapped network drive or the location bar in File Explorer, it will cache the credentials for that specific “server”.

So if you connect to the share \\192.168.0.100\documents with the user bob, then from now on it will automatically reuse bob for any share that is located on 192.168.0.100.

If you try to connect with another user (perhaps with different privileges or permissions on the share or underlying filesystem on the server), you’re out of luck! You have to clear the cached credentials and possibly even restart explorer.exe.

Even if you try to connect to a different share on the same “server”, you’re stuck with the privileges and permissions of the user bob. So let’s say you try to connect to \\192.168.0.100\archives, you cannot specify a different user (sally) to connect with. Not even temporarily, such as if you want to access the share with more or less permissions.

With Linux, you can connect as whomever you want, as much as you want, even on the same server. (Same IP address or hostname.) You can specify sally or bob as needed. Whether manually, or via the file explorer location bar, or in the fstab, or with systemd-mount, etc.

So what to do with Windows to “trick” it into thinking you’re connecting to “different servers”? Create custom hostnames under C:\Windows\system32\drivers\etc\hosts

Now it will let you use a different credential for each “server”, even though they all direct to the same server at 192.168.0.100.

This has been working fine with no issues, up until TrueNAS Core 13.3, and hence, the newer version of Samba.

Apparently (and I could be interpreting this incorrectly), it causes a long delay, because you’re trying to authenticate with a user that supposedly doesn’t exist on the server.

“The connection is telling me this is bob @ truenas.home? I am 192.168.0.100 or truenas.local. I am not truenas.home.”

Adding the custom hostnames in the TrueNAS GUI (which reflect the same hostnames in Windows’ hosts file) resolved this. No more warnings in the server’s log.smbd logfile. No more delay. Instant connection.

Windows sucks. :-1:

But from this thread, and thanks to @ddaenen1, if you have a router that supports it, you can specify multiple custom hostnames to the same TrueNAS IP address.


:point_up: Not a signature.

:point_down: Not an endorsement. :yum:

1 Like

Was serious though, I use a DNS server, which probably means that TrueNAS knows it’s hostnames.

I actually explained what I did.

But if you don’t see it, maybe you actually did fail the captcha. :exploding_head:

I ignored your single post signature :wink:

Okay, a hosts file.

Interesting solution to a problem I had but didn’t know.

Use a custom dns :wink:

I use pfsense. Planning on doing a video on using pihole as a custom dns eventually.

Perhaps the delay is to punish scanners… similar to failed ssh logins.

1 Like

I hate how forum signatures appear the same as using the “spacer” in an actual post.


Sometimes you want to partition a post into sections to make it easier to read. Especially, if you want to avoid clutter and separate distinct sections.


That’s why the last “section” of a post can accidentally be passed over, since the reader thinks it’s a signature. Kind of like this right here!

This is the “cleaner” method. I hadn’t considered it, since it was a “Windows-only” problem when I first started using FreeNAS 11.x.

It’s only after today, and from reading what @ddaenen1 did with pfSense, do I realize I could have done something similar myself. (Fresh Tomato also allows multiple custom hostnames for the same device on the network.)


WAIT! NOW I REMEMBER! As I was typing my reply, it clicked! Now I remember why I went with the “hosts file” method on Windows.

Now I remember why specifying custom hostnames on a DNS server isn’t possible for me!

It cannot work with an active VPN connection on the Windows client. The VPN software uses its own DNS server, so it bypasses the router itself. That’s why using custom hostnames on the router wouldn’t work.

But if you edit C:\Windows\system32\drivers\etc\hosts, then you can still use the custom hostnames, even if you’re using a VPN connection on the Windows client.

Yes. Most VPN software will overrride the local DNS to the remote network’s DNS otherwise you wouldn’t be able to name resolve the virtual private network names on the remote network.

If only the dns on the other side of the VPN was aware of your network’s lookup domain and could redirect the dns requests back to the authoritive DNS server on your local network.

Mine does that :slight_smile:

But I did configure both sides.

Maybe you can do a similar thing for your subdomain in the hosts file?

I’m no cyber security expert, but that sounds like it could be exploited with a yet unforeseen vulnerability in the future.

Mine (Eddie for AirVPN) does not. It has an “Allow Private LAN” option, which simply bypasses the VPN for local IP addresses. It knows nothing of aliases / hostnames.[1]


Which hosts file? The Windows one under C:\Windows\system32\drivers\etc ?


  1. Of course, editing the hosts file essentially converts hostnames into IP addresses. So Eddie (VPN software) doesn’t see a connection attempt to truenas.home, but rather to 192.168.0.100. Thus, it leaves it alone, since it’s a “local” address. ↩︎

Seems like entering the hosts into the server too is your best solution

Or figuring out how to disable this samba behavior

1 Like

I have had issues with Windows 11 where File Explorer would hang when accessing certain local drives/folders (the “Downloads” folder was very susceptible) or accessing some of my SMB shares (shares are using the TrueNAS server IP address). Some have speculated this was a Windows caching issue and needed the cache to be cleared. It didn’t work for me as far as I remember.
Long story short, I think the hanging issue (few seconds upward of 30s) seemed to be triggered when some of my “Mapped Network Drive” didn’t have an established connection to SMB shares hosted by devices that are down (ie backup TrueNAS, VM, …).

Good to know!