> The smb.conf file for the 18.04 box shows it as being a standalone server, not a domain member. Is that expected? Are you managing its users locally via smbpasswd?
After uploading I noticed that too. No it is not intended. I changed it to
security = ADS
again and added same settings as in 17.10. Unfortunately smbd is still crashing after accessing the share on 18.04.
> Was this 18.04 box a fresh install of samba 4.7.6, or did you at some point have 4.7.4 or earlier and upgrade?
I upgraded from 16.04 to the development release of 18.04 earlier this year. It is very possible that I had samba 4.7.4 at some point earlier this year.
I have another system with a fresh install of 18.04. smbd also crashes there.
> The moment I remove your "kerberos method" option (i.e., comment it), the crash no longer happens.
Hm, it still keeps crashing for me.
Now I changed smb.conf on 18.04 to this still crashing configuration:
[global]
dns proxy = No
domain master = No
kerberos method = secrets and keytab
local master = No
log file = /var/log/samba/log.%m
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
realm = MPI-DORTMUND.MPG.DE
security = ADS
server role = member server
server string = %h %a
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
workgroup = MPI-DORTMUND
idmap config * : backend = tdb
> Can you elaborate on how this 18.04 machine is supposed to authenticate users and give them access or not to a share, since it's not part of the AD realm, at least according to smb.conf?
The 18.04 machine should prefer kerberos for authenticating users. Local authentication using sssd for AD is working fine. Kerberos authentication is working fine too.
There is a shared directory users should have access. It is working the other way round - on 17.10 with same settings:
[share]
create mask = 0640
directory mask = 0750
force group = "Domain Users"
invalid users = root
path = /mnt/share
read only = No
valid users = +ntwsadmins "+Domain Users"
> The smb.conf file for the 18.04 box shows it as being a standalone server, not a domain member. Is that expected? Are you managing its users locally via smbpasswd?
After uploading I noticed that too. No it is not intended. I changed it to
security = ADS
again and added same settings as in 17.10. Unfortunately smbd is still crashing after accessing the share on 18.04.
> Was this 18.04 box a fresh install of samba 4.7.6, or did you at some point have 4.7.4 or earlier and upgrade?
I upgraded from 16.04 to the development release of 18.04 earlier this year. It is very possible that I had samba 4.7.4 at some point earlier this year.
I have another system with a fresh install of 18.04. smbd also crashes there.
> The moment I remove your "kerberos method" option (i.e., comment it), the crash no longer happens.
Hm, it still keeps crashing for me.
Now I changed smb.conf on 18.04 to this still crashing configuration:
[global] samba/log. %m samba/panic- action %d snew\s* \spassword: * %n\n *Retype\ snew\s* \spassword: * %n\n *password\ supdated\ ssuccessfully* .
dns proxy = No
domain master = No
kerberos method = secrets and keytab
local master = No
log file = /var/log/
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/
passwd chat = *Enter\
passwd program = /usr/bin/passwd %u
realm = MPI-DORTMUND.MPG.DE
security = ADS
server role = member server
server string = %h %a
syslog = 0
unix password sync = Yes
usershare allow guests = Yes
workgroup = MPI-DORTMUND
idmap config * : backend = tdb
> Can you elaborate on how this 18.04 machine is supposed to authenticate users and give them access or not to a share, since it's not part of the AD realm, at least according to smb.conf?
The 18.04 machine should prefer kerberos for authenticating users. Local authentication using sssd for AD is working fine. Kerberos authentication is working fine too.
There is a shared directory users should have access. It is working the other way round - on 17.10 with same settings:
[share]
create mask = 0640
directory mask = 0750
force group = "Domain Users"
invalid users = root
path = /mnt/share
read only = No
valid users = +ntwsadmins "+Domain Users"