Upgrade to 25.04 completely broke SMB

Hi,

I’ve recently upgraded to 25.04 (release, not RC or beta) from the previous major version (24.10 I think? but not sure). I never installed any unstable/RC/beta versions of Fangtooth.
The upgrade completely broke any and all SMB shares for (as far as I can tell) all users.

Just to be clear: all shares worked fine before the upgrade, and has for years in some cases. Users obviously have the “SMB user” set. All have a password and are in the corresponding ACLs for the shares (and on the filesystem).

No matter which user tries, I get NT_STATUS_LOGON_FAILURE on client side. Serverside I get an entry in the audit log of SMB mentioning NT_STATUS_NO_SUCH_USER. Digging a bit further and googling around, I got a forum post that mentioned pdbedit -L to check if the passwords are set, and the output was completely empty.

I checked my own user, and disabling and re-enabling the “SMB user” flag required me to reset my password, but did make my user work again for SMB. My user now also shows in the output for pdbedit -L. So it would seem the upgrade “lost” all SMB passwords for all users.

There seems to be an RC1 forum post semi-related to this issue (post number 38009, I guess I can’t even link to internal posts for some reason, title starts with “Unable to access SMB after upgrading”).
But I don’t seem to have the exact symptoms described in the reply marked as solution. The affected users do not have a unixhash is "*" in the output of that command, but a normal hash as expected.

Now my question is this: can I somehow force the re-creation of the samba password database? Setting it manually for every user is tedious and requires knowing the password. For some of the users I obviously don’t know the password, while for others the password is generally unknown (but set), as it’s an account for some sort of service that was just set once and not written down anywhere. I can of course in theory reset those, too, but that requires reconfiguring the services that use them (again, just tedious).

Should I just downgrade/restore backup, perform some sort of fix and re-apply the update so it can complete correctly? What’s the easiest way forward? Please note that the ZFS pools have been upgraded already (but new features aren’t actively in use yet), not sure if that’s a problem?

Thanks
Creat

As has been mentioned a few times, this isn’t limited to one or two affected users. It’s the presence of any SMB user with the unixhash set to “*”.

1 Like

Ah I missed that detail, thanks. I did uncheck the “SMB user” for those that do not have a password set. That alone also doesn’t seem to fix the issue by itself. I assume there are some steps I can follow to get this resolved, could you maybe just provide a link? Edit: trying a reboot real quick. Update: yup, fixed! Thank you!

In that one thread I did find, you mention that there’s a warning for this now, but I didn’t see any warnings during or after the upgrade? Not sure if I just missed it or something?

It might be nice if this could be mentioned in the “notable changes” or “known issues” in the release notes. I did check them before and didn’t see anything that seemed to apply to me. I now checked again, and this doesn’t seem to be listed at all. Breaking all of SMB just because one/some user(s) have the “SMB user” flag set without having a password set as well doesn’t seem like an outlandishly unlikely constellation to find in the wild.