Unable to access SMB after upgrading from 24.10.2 to 25.04-RC.1

TrueNAS General
1

Hi, I currently have TrueNAS on a VM within PVE. Whenever I boot into 25.04-RC.1, I am unable to access my SMB share from anything (Linux server, Windows desktop). The only way I am able to access the SMB share is if I boot to the previous version (24.10.2). I am at a loss; my share/filesystem ACLs are the same, the share name is the same, the only thing that should theoretically be different is the version I upgraded to. I did check the release notes and it mentioned auxiliary parameters, which I do not seem to have.

Like I said earlier, when I boot to 24.10.2 while keeping everything the same, I am able to connect just fine. What am I doing wrong…?
Thank you in advance!

2

Sorry for no pictures, it seems I don’t have trust level yet.

3

Try checking that your login user has a shell selected… even if its the “nologin” shell.

Screenshot 2025-03-31 at 12.59.30 PM
Screenshot 2025-03-31 at 12.59.30 PM830×222 1.6 KB

4

Hi and welcome to the forums.

You should be able to post screenshots now. Can you share a screenshot of your dataset ACL.

5

Aux Parameters:

aux
aux390×119 3.93 KB

Filesystem ACLs:
filesystem
filesystem1228×745 28.3 KB

Share ACLs
share
share464×866 10.8 KB

image
image1633×381 17.6 KB

I tried making a whole new SMB dataset (not in these pictures) and that didn’t work either for extra info.

6

Didn’t work unfortunately…

image
image399×472 4.92 KB

7

Let’s see full share config. midclt call sharing.smb.query | jq

8

See attached:

[
  {
    "id": 10,
    "purpose": "DEFAULT_SHARE",
    "path": "/mnt/data_pool/true-share",
    "path_suffix": "",
    "home": false,
    "name": "true_share",
    "comment": "",
    "ro": false,
    "browsable": true,
    "recyclebin": false,
    "guestok": false,
    "hostsallow": [],
    "hostsdeny": [],
    "auxsmbconf": "",
    "aapl_name_mangling": false,
    "abe": false,
    "acl": true,
    "durablehandle": true,
    "streams": true,
    "timemachine": false,
    "timemachine_quota": 0,
    "vuid": "b574d8fb-9f44-4cd0-83c2-1f94f5c9e1ba",
    "shadowcopy": true,
    "fsrvp": false,
    "enabled": true,
    "afp": false,
    "audit": {
      "enable": false,
      "watch_list": [],
      "ignore_list": []
    },
    "path_local": "/mnt/data_pool/true-share",
    "locked": false
  }
]

Here is more weirdness from the audit log:

Logon ID: '0'
Logon Type: 3
Local Address: ipv4:192.168.50.136:445
Remote Address: ipv4:192.168.50.189:48422
Service Description: SMB2
Auth Description: Null
Client Domain: ''
Client Account: dyfinder
Workstation: proxmox-debian
Became Account: Null
Became Domain: Null
Became Sid: Null
Mapped Account: dyfinder
Mapped Domain: ''
Netlogon Computer: Null
Netlogon Trust Account: Null
Netlogon Negotiate Flags: '0x00000000'
Netlogon Secure Channel Type: 0
Netlogon Trust Account Sid: Null
Password Type: NTLMv2
Client Policy Access Check: Null
Server Policy Access Check: Null
Vers:
  Major: 0
  Minor: 1
Result:
  Type: NTSTATUS
  Value Raw: 3221225572
  Value Parsed: NT_STATUS_NO_SUCH_USER

image
image1635×383 10.5 KB

For some reason, it’s acting like the user doesn’t exist…

9

We had one additional bug filed against RC1 where users had configured SMB accounts with empty passwords (unexpected configuration that wasn’t caught in validation) which resulted in failure to generate samba’s passdb.tdb file. Maybe run command midclt call user.query '[["smb", "=", true]]' '{"select": ["username", "unixhash"]}' | jq and review results for users whose unixhash is "*". If you have one, either turn off SMB for the account or set a valid password.

10

THANK YOU!!! That was the issue. I had one user that had the unixhash you described as a password. Once I deleted that user, I rebooted the machine (as it still wasn’t working). Once it rebooted, I checked and I can now access my share.

11

25.04.0 will create alerts for broken SMB users.

class SMBUserMissingHashAlertClass(AlertClass, SimpleOneShotAlertClass):
    category = AlertCategory.SHARING
    level = AlertLevel.WARNING
    title = "SMB user is missing required password hash"
    text = (
        "The following users lack valid password hashes. "
        "This may occur if the TrueNAS configuration was restored without the "                                                                   "secret seed and may be fixed by resetting the user password through the "
        "TrueNAS UI or API: %(entries)s"
    )

These issues started to appear in 25.04 because the code for how SMB users are generated was significantly refactored to improve performance, and during BETA / RC exposed some unanticipated configurations.

2 Likes