A guess, given the information you have given so far, is that you have a user missing a password.
But really, you should make your own thread and post more details there. It will be difficult for anyone to assist you further in the release thread.
@neofusion Are you replying to me? If so, that it is not correct. A quick search will show you quite a number of people who could not see the SMB shares after upgrading. Some people were able to get it working by changing the profile from multi NFS/SMB to default. That did not work for me
Iāll say it again:
You should post your own thread so you can supply detailed information on your setup and hopefully get the help you need.
@neufusion My response is in the correct place. It is targeted to people who use SMB and maybe at risk of a failed upgrade. Therefore, it is a warning, they may want to check in more detail before upgrading.
For me, I reverted to 24.10.2 boot environment and will wait till 25.04.1 before trying again based on the issues identified by searching the problem. p.s. I note that all the bug reports have been closed, despite not providing any fixes
2 Likes
@awalkerix Good to know, thanks. Do you know if there is a workaround to fix it?
Okay, I tried.
If everyone had the same issues with SMB after updating as you do, we would seen a flood of reports in the forums.
I wish you the best of luck getting your issue sorted.
Yes, as is mentioned in various forums threads about this issue, fix your users (you configured some as SMB users with an empty string as a password). c.f. commit message and jira ticket.
The issue he linked was the same I guessed was the cause, the one you said was incorrect.
Namely, having users with no password.
The fix is to make sure every SMB-user has a password.
Or donāt make service accounts SMB users (since they often donāt need to be such).
1 Like
@awalkerix Andrew, I donāt believe that is the issue. The users must authenticate with a password with both home and shared directories. Also in linux clients, the users use the .smbcredentials with autofs to authenticate
The profile after migration showed as mixed nfs/smb.
I tried changing to default and to private smb, but neither made any difference. However, for other users changing to default seems to solve their problem.
Each user has their own account in truenas and the linux user_id is the same number as the user_id on the linux clients.
I donāt believe that is the issue.
And if you look at the forums thread and jira ticket, thatās how the conversations always start 
3 Likes
Andrew, maybe I am missing something.
- my userid (linux clilent) is the same as my userid on truenas.
- the userid has a password on the linux client which is the same as the truenas userid password
- autofs mapping is -fstype=cifs,rw,credentials=/root/.smbcredentials-${USER},uid=${USER},gid=${USER} ://truenas
- the SMB share has ACL enabled and browse network checked
What youāre likely missing is that the issue may not have anything to do with that account, but just any account that has a blank password configured.
Take a look at this thread SMB Authentication breaking after TrueNAS (FT) reboots
2 Likes
Thanks btw. This āSSH password login enabledā was unchecked on a new install. I guess I must have done this 8+ years ago when I first installed Truenas and it carried over. I see no other way of deleting these docker stacks other than via winscp / root.
In my case emby user had smb enabled. i removed it but still didnāt work.
when i tried to change the password of my own account i get,
EINVAL] user_update.groups.1: users: membership of this builtin group may not be altered. [EINVAL] user_update.groups.5: systemd-journal: membership of this builtin group may not be altered.
my user is a member of builtin_administrators and systemd-journal if that explans anything
p.s. canāt remove either group membership
Why did you make a user account a member of those groups?
I have been upgrading from freenas core to truenas core to scaleā¦ You ask me, I ask who. I donāt remember. but my account seems to be the only one.
my userid is the only one that is a member of systemd.journal but i canāt remove it from either the user or the group screens.
my userid and root was a member of the builtin-adminstrator. I was able to remove via the group screen
Getting the below errors in the log
[2025/04/30 23:15:26] (DEBUG) middlewared.api.base.handler.model_provider.get_model():55 - Importing 'middlewared.api.v24_10'
[2025/04/30 23:15:28] (ERROR) middlewared.job.run():530 - Job <bound method SMBService.synchronize_passdb of <middlewared.plugins.smb_.passdb.SMBService object at 0x7f9a930b3390>> failed @cee:{"TNLOG": {"exception": "Traceback (most recent call last):\n File \"/usr/lib/python3/dist-packages/middlewared/job.py\", line 515, in run\n await self.future\n File \"/usr/lib/python3/dist-packages/middlewared/job.py\", line 562, in __run_body\n rv = await self.middleware.run_in_thread(self.method, *args)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/usr/lib/python3/dist-packages/middlewared/main.py\", line 599, in run_in_thread\n return await self.run_in_executor(io_thread_pool_executor, method, *args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/usr/lib/python3/dist-packages/middlewared/main.py\", line 596, in run_in_executor\n return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/usr/lib/python3.11/concurrent/futures/thread.py\", line 58, in run\n result = self.fn(*self.args, **self.kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/usr/lib/python3/dist-packages/middlewared/plugins/smb_/passdb.py\", line 89, in synchronize_passdb\n insert_passdb_entries(to_update)\n File \"/usr/lib/python3/dist-packages/middlewared/plugins/smb_/util_passdb.py\", line 363, in insert_passdb_entries\n samu_data = _pack_pdb_entry(entry)\n ^^^^^^^^^^^^^^^^^^^^^^\n File \"/usr/lib/python3/dist-packages/middlewared/plugins/smb_/util_passdb.py\", line 256, in _pack_pdb_entry\n data += _pack_samba_pascal_string(bytes.fromhex(entry.nt_pw))\n ^^^^^^^^^^^^^^^^^^^^^^^^^^\nValueError: non-hexadecimal number found in fromhex() arg at position 0", "type": "PYTHON_EXCEPTION", "time": "2025-04-30 21:15:28.064680"}}
[2025/04/30 23:15:28] (ERROR) ServiceService.reload():370 - Service 'mdns' not running after reload
You can delete and recreate the account properly with same uid / gids if you want to fix this (NOTE: that changing membership of system groups is not permitted now)