Time Machine cannot connect to SMB Share (Dragonfish 24.04 RC1)

After upgrading to Dragonfish (24_04 RC1), Time Machine can no longer connect to the SMB Share.
If I revert to Cobia 23.10.2, it all works fine.

I suspect that some SMB permission has changed between releases. Will look into it more when I have some time, but for now its back to Cobia 23.10.2

Ive also raised a ticket (NAS-128229), so hopefully it will get resolved soon

[2024/04/06 15:38:37.844255,  1] ../../source3/smbd/session.c:69(session_claim)
  pam_session rejected the session for tmachine [smb/689779730]

The logs are pretty clear that it’s caused by PAM. Since you have a home share we have to set obey pam restrictions = true in order to have the feature in which we auto-create home directories via pam_mkhomedir. Having a session rejection means that the user in question is misconfigured for this purpose (missing home directory, having invalid shell, etc).

Current settings for Userid tmachine:

Home Directory: /nonexistent
Shell: /usr/bin/bash
Email:xxxxxxx@gmail.com
Password Disabled: No
Lock User: No
Samba Authentication: Yes
SSH: Password login enabled

User has a shell, and account is enabled, so I’m assuming that “/nonexistent” is no longer valid.
Odd as I have other accounts with this setting that I can log in with…
Nevertheless I’ll try to set a real home directory tomorrow and see if that works.

Note though, this does work in 23.10.2

/var/empty is the new default for home directories. This was partially to ameliorate issues with libpam session management, and prevent cases in past versions where users could accidentally (or intentionally) create a /nonexistent directory.

1 Like

Thanks @awalkerix, that fixed the problem.

Strangely, my admin account has “/nonexistent” and it has no problem logging into my Truenas server. I assume its only when you are using the ID for SMB access that its an issue.

You may also want to update the documentation here to the new default for for no directory.

Thanks. I notified our documentation team.

We use PAM authentication, but not PAM session for UI logins so from a technical perspective this is not surprising.