After upgrade to DragonFish only MacOS can connect to SMB. Linux and Windows can't

[runevn]

I have upgraded to Dragonfish-24.04.0 and after the upgrade only Mac OS can connect to the share. My Windows 10 and Linux (Debian 11) machines can’t connect. Before the upgrade all shares have been worked perfectly.

I’m sure that my username and password is correct. I have attached log output and screen dumps from my Truenas setup.

Please let me know if you need additional information.

Thanks in advance.

On my Debian 11 machines I get the following error messages:

mount.cifs kernel mount options: ip=192.168.25.2,unc=\\192.168.25.2\media,vers=3.1.1,user=nextcloud,domain=mydomain,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

/var/log/syslog

│Apr 30 10:23:36 nextcloud kernel: [88398.470351] CIFS: Attempting to mount //192.168.25.2/media                                                                         │
│Apr 30 10:23:36 nextcloud kernel: [88398.483717] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE                                                             │
│Apr 30 10:23:36 nextcloud kernel: [88398.483725] CIFS: VFS: \\192.168.25.2 Send error in SessSetup = -13                                                                │
│Apr 30 10:23:36 nextcloud kernel: [88398.484727] CIFS: VFS: cifs_mount failed w/return code = -13    

/var/log/kern.log

Apr 29 09:50:36 nextcloud kernel: [   19.736435] FS-Cache: Loaded                                                                                                       │
│Apr 29 09:50:36 nextcloud kernel: [   19.738683] Key type dns_resolver registered                                                                                       │
│Apr 29 09:50:36 nextcloud kernel: [   19.820407] FS-Cache: Netfs 'cifs' registered for caching                                                                          │
│Apr 29 09:50:36 nextcloud kernel: [   19.827869] Key type cifs.spnego registered                                                                                        │
│Apr 29 09:50:36 nextcloud kernel: [   19.827873] Key type cifs.idmap registered                                                                                         │
│Apr 29 09:50:36 nextcloud kernel: [   19.828198] CIFS: Attempting to mount //192.168.25.2/nextcloud-storage                                                             │
│Apr 29 09:50:36 nextcloud kernel: [   19.828227] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), fro│
│Apr 29 09:50:36 nextcloud kernel: [   20.042782] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE                                                             │
│Apr 29 09:50:36 nextcloud kernel: [   20.042792] CIFS: VFS: \\192.168.25.2 Send error in SessSetup = -13                                                                │
│Apr 29 09:50:36 nextcloud kernel: [   20.042834] CIFS: VFS: cifs_mount failed w/return code = -13                              

dmesg

[   19.736435] FS-Cache: Loaded
[   19.738683] Key type dns_resolver registered
[   19.820407] FS-Cache: Netfs 'cifs' registered for caching
[   19.827869] Key type cifs.spnego registered
[   19.827873] Key type cifs.idmap registered
[   19.828198] CIFS: Attempting to mount //192.168.25.2/nextcloud-storage
[   19.828227] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[   20.042782] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
[   20.042792] CIFS: VFS: \\192.168.25.2 Send error in SessSetup = -13
[   20.042834] CIFS: VFS: cifs_mount failed w/return code = -13

Event data from Truenas Audit log:

Logon Id: '0'
Logon Type: 3
Local Address: ipv4:192.168.25.2:445
Remote Address: ipv4:192.168.20.25:51122
Service Description: SMB2
Auth Description: Null
Client Domain: ''
Client Account: nextcloud
Workstation: ''
Became Account: nextcloud
Became Domain: NAS
Became Sid: S-1-5-21-1342993578-1548047799-2758588834-20039
Mapped Account: nextcloud
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: 0
  Value Parsed: SUCCESS

[chuck32]

I currently don’t have the time to search and link all the other posts but I’ve seen so many posts in the last weeks that all had the same error under Linux, maybe there’s and underlying bug?

mount error(13): Permission denied

[runevn]

I have tried further finding the issue by using another user, which actually succeed to mount the SMB share.

I have changed the password of the user that does not work to 123456 and it still doesn’t work. I have furthermore added the non-working user to the same groups as the user that does work are a member of.

I really can’t get what causes the problems…

This is the non-working user:

This is the working user:

[ABain]

@runevn I am assuming the share and original user existed before upgrade? I tried setting up a fresh set and confirmed no issues and we didn’t get reports on upgrade. Please could you raise a bug ticket with a debug to allow us to investigate.

[runevn]

Yes, both users and the share were the same before the upgrade.

I just created a new user “test” with the password 123456 and belonging to Wheel group and that user also worked.

The only difference I see when looking at the users is that the user that doesn’t work has a “/nonexistent” home directory.

And sure I will raise a bug ticket. Thanks

[runevn]

Okay, it seems that it is actually the issue with the /nonexistent home directory. I added the home directory to the non-working user and it did success in mounting the SMB share.

I guess there has been some changes related to the implementation of SMB in the Dragonfish…

However, I would be nice if a home directory would not be required.

[awalkerix]

The home directory is only required if you’re using a home share. There is no way around it for SMB, the only reason this was accidentally working in Cobia with /nonexistent was because our root filesystem wasn’t readonly.

[runevn]

Okay, thanks for your reply. So, if I understand you correctly. All users mounting SMB share should have a home directory? Or can I somehow have a SMB user without a home directory?

[awalkerix]

This only matters if you have an SMB share you have created with home checked.

[runevn]

Okay, but at the moment I need to create a home share directory for all users that I use to connect to any share on the NAS. Are there any solution or way to not have to create a home directory for all SMB users?

[awalkerix]

You can change them to /var/empty no need to create a home directory.

[runevn]

Perfect, and thanks for the solution. I really appreciate your help.

[runevn]

Sorry for keep asking questions. If I create a new user and don’t check “Create Home Directory” I get this warning.

Does this mean that user data/settings will be stored in the homes directory?