Rechte Probleme seit Samba 4.2 Update

[aubergine]

Hi,

ich habe seit dem heutigen Debian Upgrade (Samba 4.2, Kernel, etc) massive Probleme mit Samba.

Die Konfiguration des shares sieht wie folgt aus. Es handelt sich bei user1 und user2 um lokale Benutzer.

Code: Alles auswählen

[share]
   comment = share
   path = /srv/samba/share
   browseable = no
   writable = yes
   valid users = user1 user2
   write list = user1
   create mask = 0600
   directory mask = 0700
   force user = nobody
   force group = nogroup

Bisher waren alle Ordner- und Dateisystemrechte unterhalb und inklusive /srv/samba/share wie in der Konfiguration angelegt.
Seit dem Upgrade können user1 und user2 nicht mehr auf den Share zugreifen. Einhängen klappt, mehr nicht.

Wenn ich nun force user und group auf root setze klappt der Lese- und Schreibzugriff wieder.

Es scheint sich etwas massiv geändert zu haben und ich komme nicht darauf was. Meine übrige Samba Konfiguration findet ihr unten angehängt. Ich habe keine Domain, die Benutzer sind lokal im System sowie über smbpasswd angelegt. Als Client ist ein weiteres Debian und ein Windows 10 vorhanden. Auf beiden Clients ist das Verhalten seit dem Update des Servers gleich.

Das Einzige was meine bisherige Fehlersuche ergeben hat ist dass sich das Verhalten von winbind geändert hat. Zumindest das Anzeigen der zwei lokalen Samba User hatte bis vor dem Update geklappt.

Code: Alles auswählen

root@nas:~# wbinfo -u
Error looking up domain users
root@nas:~# wbinfo -g
failed to call wbcListGroups: WBC_ERR_DOMAIN_NOT_FOUND
Error looking up domain groups

smb.conf

Code: Alles auswählen

[global]
   workgroup = WORKGROUP
   wins support = yes
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = no
   security = user
   encrypt passwords = true
   invalid users = root
   guest account = nobody

   client ipc signing = auto
   ntlm auth = no

   local master = yes
   preferred master = yes
   os level = 254

   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[rendegast]

jessie samba 4.1 -> 4.2, aua, aua.

Ist das Upgrade sauber durchgelaufen? Ohne Meldungen?

Code: Alles auswählen

dpkg -l | egrep "samba|winbind|wb|4.2.10|4.1.17"
dpkg -l | egrep -v "^ii"

Für Vergleich und Aufarbeitung die Standardwerte mit leerer smb.conf

Code: Alles auswählen

testparm -v > 4.2-Werte

Dann nach 4.1 zurück, per backup oder Reinstallation der 4.1-Pakete

Code: Alles auswählen

# apt-cache policy samba
samba:
  Installed: 2:4.2.10+dfsg-0+deb8u2
  Candidate: 2:4.2.10+dfsg-0+deb8u2
  Version table:
 *** 2:4.2.10+dfsg-0+deb8u2 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2:4.1.17+dfsg-2+deb8u2 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages

Deine Infrastruktur sollte dann erstmal wieder funktionieren.

Nochmal ein Festhalten der default-Werte mit leerer smb.conf

Code: Alles auswählen

testparm -v > 4.1-Werte

Auf der Basis der Unterschiede in 4.1-Werte und 4.2-Werte
(ich empfehle für Übersichtlichkeit die beiden Dateien noch zu sortieren)
kannst Du Deine Konfig durcharbeiten/angleichen,
zBsp. auf einem parallelen Server in VM mit samba 4.2.
Problem dabei, welchem vorzubeugen ist, wäre winbind der beiden Server.

[aubergine]

Dieses Debian "Security" Update auf Samba Version 4.2 kommt in meine Top 10 der Debian Fails. Die Zeiten in denen man per Cronjob aktualisieren konnte scheinen vorbei zu sein...
Aber egal das ist zusammen mit systemd ein anderes Thema

Ich habe mittlerweile herausgefunden was Samba 4.2 stört, aber leider nicht warum.

Wenn ich force user und force group auf irgendetwas anderes wie nobody:nogroup setze und einen entsprechenden chown auf den Share mache, dann funktioniert wieder alles.
Nur mit nobody:nogroup funktioniert es nicht mehr und dabei ist egal auf welchen Wert guest account gesetzt ist, ich dachte nämlich zuerst es liegt daran dass der guest account und force user beide gleichzeitig auf nobody stehen.

Dabei sieht der User nobody ganz normal aus:

Code: Alles auswählen

root@nas:~# id nobody
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)