MacOS will Not Connect to Scale SMB Shares via UN/PW (But Will With Guest Account)

TrueNAS General
1

Hey all,

I have several SMB shares on TrueNAS Scale that I just cannot connect to with MacOS with username and password regardless of what I do. MacOS login screen just gives the error “wiggle” - as if the credentials are incorrect. Attempting to mount with mount -t smbfs //user@server/share ./somefolder results in an authentication error (err 77) after being prompted for a password and typing in the correct one.

It’s never really worked well for me on Scale (I’ve updated from Bluefin, where the same behavior occurred, to the latest Cobia). Previously, I could sometimes connect by 1) stripping the ACL off the dataset, 2) adding the ACL back to the dataset - when doing this, I could sometimes connect ONCE (future attempts to connect resulted in failure). Now, (I think after updating to Cobia), this method doesn’t work anymore.

I can successfully connect to the shares:

  1. From a Windows 11 virtual machine, so I know that the UN/password is correct, the share is properly configured, etc

  2. From MacOS using a guest account if I enable guest access on the dataset

  3. From Linux machines on my home network

I should add I’m connecting over a VPN (Wireguard), but I have the same problems on my wifi at home. I haven’t had my Macbook at home since upgrading to Cobia… And I am using the IP, not the host name. The VPN is configured correctly - Windows 11 can connect to the share with UN/password over the VPN, and I can get to the web interface, etc.

I’ve scrubbed my keychain for old credentials and deleted all references to my TrueNAS server…but this really shouldn’t factor in as I type the password in each time I’m attempting to connect. Anyone have any ideas on what to try next? Is there something I need to do from MacOS? A setting I’ve missed in TrueNAS Scale? Is there a good way to diagnose / troubleshoot? Logs I should be looking at (on MacOS and/or Scale)?

I’m thinking that the err 77 using the command line mount is maybe the most telling data point so far.

2

Have you tried using smb:// instead of //?

Not sure if that will work, but I always use smb:// in the Connect to Server dialog.

3

I gave that a try with the mount command - same result. I do use smb:// in the GUI finder dialog box.

Good idea. Thanks!

EDIT: It appears to be some sort of issue with how the smb client on MacOS authenticates with truenas. Not sure how I could inspect the traffic, or if anyone has specific knowledge of MacOS’ smb client.

4

What version of SCALE, what version of MacOS?

If using Dragonfish 24.04, what does the System → Audit say about the SMB login attempt, if anything?

5

Per a comment here: Reddit - Dive into anything, I created /etc/nsmb.conf with the following:

[default]
signing_required=no
streams=yes
notify_off=yes
port445=no_netbios
soft=yes
dir_cache_max_cnt=0
dir_cache_max=0
dir_cache_off=yes
protocol_vers_map=4
validate_neg_off=yes
mc_on=yes
mc_prefer_wired=yes

I can now connect ONLY via command line after a reboot, and I can only connect once. If I mount, umount and then mount again, I get the same authentication error. If I try to use the finder GUI as the first after reboot method of connecting to the share, it does not work, and after I try via the GUI, the mount command will not work either, once again. This really seems like a MacOS thing - maybe due to caching - but it would be nice to poke into some log files to at least attempt to see what’s happening.

6

Oops. Missed this comment.

MacOS Sonoma 14.5
TrueNAS Scale 23.10.2 Cobia (but as mentioned, this has been the behavior on Bluefin as well)

Is the upgrade to Dragonfish worth it for the System → Audit tool? I always get a bit worried when doing an upgrade remotely (I’m away from home for a few months).

7

I definitely wouldn’t recommend a remote upgrade. The Audit functionality is potentially helpful but but not required.

I am sceptical of customising the nsmb.conf just to be able to login; it should not be necessary.

Instead I suggest you try this:

  1. Check your client computer’s Keychain for any related saved password by searching for your NAS’s hostname and assuming you know the username and password, delete those records from the keychain (it might be in there several times with different names).
  2. Reboot the client. This should clear the cache.
  3. Now try logging in using the “Connect to Server…” dialogue window using your known good credentials, connect using smb://serverhostname, nothing more.
1 Like
8

This is very interesting. I’ve done 1-2 already - I don’t store the info in my keychain anymore since I’ve had issues with this. I connected using your recommendation in #3 - simply using the server IP. After specifying username and password via the dialog that comes up, MacOS asked me which share I want to connect to (I have a few accessible from this UN). I cannot connect when specifying a username (i.e. smb://user:*@server, but connected just fine with smb://server. Now, it’s clear the the UN/pass are being cached, because disconnecting, then attempting to connect again, I’m not asked for a UN/pass and the original credentials I typed are used. I can also specify a share now smb://server/share. It’s not clear to me whether that would have worked to start with, but it seems like the issue was specifying a user for some reason. I’m cautiously optimistic that it works now. I’ll keep an eye on it and post back if I encounter future issues. Thanks!

So to recap, the solution is to:

  • Connect with smb://server and/or possibly with smb://server/share NOT smb://user:*@server
  • I did not cache credentials in the keychain, but that may or may not cause issues. Not sure at this point - I’ll have to test more.
1 Like