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

TrueNAS General
,
1

Not sure if this is a bug, and I’m not sure if I overlooked something.

The short of it is…

:smiley: Core 13.0-U6.1: SMB shares work flawlessly, whether connecting from Windows or Linux clients.

:skull: Core 13.3: Connecting to any SMB share, whether Windows or Linux, will randomly (and sometimes often) “hang” the file explorer, until it eventually connects. From here, it performs as expected, and browsing or loading files is very fast.

No options were changed in the SMB service or any shares before or after the upgrade.

No auxiliary parameters are used.

Windows is the most affected by this, but Linux (Arch and Ubuntu) will sometimes face this problem.

This thread isn’t to troubleshoot or diagnose a potential bug. I’m just curious if anyone else who upgraded from 13.0 → 13.3 has noticed a similar issue with (re-)connecting to their SMB shares.

UPDATE: Likely related to using a custom hostname and/or the updated version of Samba.

UPDATE AGAIN: I might have discovered a possible solution.

UPDATE ALTERNATIVE: An alternative approach to adding custom hostnames within the TrueNAS GUI (i.e, Network → Global Configuration → Host Name Database), is to add them in your router’s DNS / resolve config. Such supported routers / firmware include pfSense, Fresh Tomato, and DD-WRT. (Thanks to @ddaenen1 for sharing this.)
This method will not work if you’re using VPN software on your client PC.

1 Like
2

On 13.0, was usually access the entire Nas from my PC from the network shared resource (according to my user ACL obv).
After upgrading this was not possible anymore, at least for me, got to map share and access them from local computer.
I got a warning from Nas, with a dump file to Share on ticket… but seems i was doing that wrong somehow.
Honestly don’t know if Is related, but i have those connection delay too.

1 Like
3

Upon playing around further, I found a common denominator (at least in my case).

If I use the server’s IP address directly, it (re-)connects to the SMB share instantly.

If I use a custom hostname, it stalls the file explorer, until it eventually connects.

The only interesting entry in the logfile (log.smb) reads:

parse_dfs_path_strict: Hostname truenas.home is not ours.

But there is no issue with performance, file and folder access, browsing directories, transferring files, and so on. The only issue is the 20-30 second delay when (re-)connecting after some time has passed. (I’m not sure the log entry is even relevant.) After it connects (even if it hangs the file explorer for 30 seconds), the share works normally.

I tested this out on a new “Default preset” SMB share. Same exact behavior. The only relief comes from using the IP address directly.

This issue started after upgrading to TrueNAS Core 13.3-RELEASE.

With Core 13.0-U6.1, this never happened. Not even once.

1 Like
4

Possibly related:

Maybe something in the update to Samba is an underlying factor, since it can occur with SCALE as well?

5

I also had this problem once upon a time, but it seemed to just go away eventually.

6

It’s never happened once to me, until I upgraded to Core 13.3.

It’s not going away. It’s 100% reproducible. (And it hangs file explorer on the client.) :frowning_face:

The problem is, I can’t use the server’s IP address for all shares, because Windows automatically reuses the same credentials for a hostname/IP when connecting to an SMB share.

That’s why I use custom hostnames. (Which worked perfectly fine with every previous version of Core.)

But it’s not really the “Core” upgrade that causes this. It’s the update to the version of Samba. (My guess is that it can also occur with SCALE, as seen by this post, after someone upgraded their SCALE server.)

1 Like
7

I experienced this very rarely on 13.0, but not frequent enough to actually track and investigate the issue beyond blaming Windows.

Have not used 13.3 much, but I didn’t encounter this behaviour yet.

1 Like
8

@awalkerix Is there an auxiliary parameter I can use that undoes this behavior?

Are you familiar with the change (in this updated version of Samba) that is triggering this?

There are situations where you want to use custom hostnames to connect to different SMB shares from the same client.

9

After some research, I think I found a solution.

Navigate to Network → Global Configuration → Host Name Database

In this text field, add your custom hostnames, one by one, in this format:
127.0.0.1 localhost truenas.local
127.0.0.1 localhost truenas.home
127.0.0.1 localhost guestnas.home

…and so on.

:warning: A server restart was required.

Now, connecting or reconnecting to an SMB share happens almost instantly. :partying_face: It doesn’t matter which hostname is used. It doesn’t matter if it’s from Windows or Linux.

I have tested this multiple times, over and over again, and it appears to be a consistent fix. :+1:

No longer does Windows File Explorer hang for over 30 seconds just to connect.

I don’t believe this is unique to TrueNAS Core or FreeBSD. I think it’s due to a new version of Samba that was introduced some time between the release of Core 13.0 and 13.3.

In fact, this likely also applies to newer versions of TrueNAS SCALE.

2 Likes
10

Weird, but hey: it’s Windows.

1 Like
11

More accurately, Windows File Explorer wasn’t the “cause” of this new issue, but rather it indicated that there was a problem on the server’s side that needed to be addressed.

At least now, after applying the above “fix”, it behaves the same as it did on TrueNAS Core 13.0. Connects instantly, no delays, no hanging. :slightly_smiling_face:

1 Like
12

THIS-IS-NOT-A-STOCK-PHOTO

DO YOU HAVE TROUBLE BUILDING YOUR CREDIT SCORE??? CLICK HERE TO FIND OUT HOW CREDINSTA™ CAN HELP!! 1-800-4535-32423234-234234-234234!!! SUCH MORE GOOD LEGIT COMPANY.

EDIT: Forgot to log into my other sockpuppet account. :sweat_smile:

13

Did the upgrade to 13.3 last weekend. I have several SMB shares but haven’t detected any issue with them. They behave as before and no delays.

14

Are you using custom hostnames to connect to the shares from your client(s)?

15

I do use the hostnames yes. I use pfSense as router and the hostnames are registered in the DNS resolver. I am on MacOS though. I do have a Win11 workstation but also there, i haven’t noticed anything extraordinary.

16

When you connect from a Windows client (using a custom hostname not defined in TrueNAS GUI’s Hostname/Domain in the Network Global Configuration page), do you get this message near the end of your log.smb logfile?

parse_dfs_path_strict: Hostname custom.domain is not ours

When SSH’d into the TrueNAS server, can you ping a custom hostname from within?

Such as, ping custom.domain

17

Can’t give you an answer to the first question but i did just SSH into my TrueNAS server from my Macbook and yes, i can ping my SMB share.

image

2 Likes
18

Now I see.

I could technically do the same thing on my Fresh Tomato router, but since it’s working now (adding the hostnames in the TrueNAS GUI), I’m happy with the result.

So there could be at least two possible workarounds if someone notices delays connecting to their SMB shares. :+1:

Using the TrueNAS GUI method doesn’t require a router/firmware that supports said feature. So at least those without DD-WRT, Fresh Tomato, pfSense, etc, can still try that.

1 Like
19

How are you making these custom hostnames?

20

Benefits from being a secret agent for multiple agencies.

1 Like