• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[workaround] Samba: Zugriff auf [homes]-Freigabe verweigert

Hi,

eine bisher funktionierende [homes]-Freigabe meines Samba-Servers tut nicht mehr. Ich erhalte auf den Windows-Rechnern (2x Win7 und Win10) die Meldung, dass der Zugriff verweigert wurde. Der Zugriff auf die gemeinsam genutzte Verzeichnis-Freigabe (siehe unten [Netzwerkspeicher]-Block) funktioniert jedoch weiterhin ohne Probleme. Einziger Unterschied zwischen "vorher" und "nachher" war nur ein Neustart des Rechners, auf dem der Samba-Server läuft.

Nach längerer Suche im Internet habe ich keine Abhilfe gefunden und frage deshalb nun hier nach einer Hilfestellung. Im folgenden stelle ich einige Daten vorab zur Verfügung.

linux-5h2s (besagter Rechner, auf dem der Samba-Server läuft):
  • Samba-Version: 4.6.5+git.32.af7a173b7a1-1.1-x86_64
  • Linux: openSUSE Leap 42.3 mit Kernel 4.4.79-19-default


/etc/samba/smb.conf
Code:
[global]
	workgroup = HOMENET
	passdb backend = tdbsam
	map to guest = Bad User
	usershare allow guests = No
	add machine script = /usr/sbin/useradd  -c Machine -d /var/lib/nobody -s /bin/false %m$
	domain logons = No
	domain master = No
	security = user
	username map = /etc/samba/smbusers
	wins support = No
	ldap admin dn = 
	wins server = 

[homes]
	comment = Persönliches Laufwerk
	path = /srv/data/private/%S
	browseable = No
	read only = No
	force create mode = 0644
	force directory mode = 0750
	valid users = %S, %D%w%S
	inherit acls = Yes

[Netzwerkspeicher]
	comment = Familien-Laufwerk
	path = /srv/data/public
	read only = No
	force create mode = 0664
	force directory mode = 0775
	force user = chief
	force group = users
	inherit acls = Yes

Auszug /var/log/samba/log.smbd (14:29 Uhr fand der besagte Neustart des Rechners statt):
Code:
[2017/08/27 14:29:47.085767,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'smbd' finished starting up and ready to serve connections

Auszug /var/log/samba/log.nmbd:
Code:
[2017/08/27 14:29:46.855735,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2017/08/27 19:44:34.811729,  0] ../source3/nmbd/nmbd.c:58(terminate)
  Got SIGTERM: going down...
[2017/08/27 19:45:30.118554,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'nmbd' finished starting up and ready to serve connections

Code:
# systemctl status smb
● smb.service - Samba SMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2017-08-27 14:29:47 CEST; 5h 44min ago
  Process: 2993 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
 Main PID: 3199 (smbd)
   Status: "smbd: ready to serve connections..."
    Tasks: 7 (limit: 512)
   CGroup: /system.slice/smb.service
           ├─ 3199 /usr/sbin/smbd -D
           ├─ 3228 /usr/sbin/smbd -D
           ├─ 3229 /usr/sbin/smbd -D
           ├─ 3299 /usr/sbin/smbd -D
           ├─ 8837 /usr/sbin/smbd -D
           ├─15433 /usr/sbin/smbd -D
           └─18777 /usr/sbin/smbd -D

Aug 27 14:29:46 linux-5h2s systemd[1]: Starting Samba SMB Daemon...
Aug 27 14:29:47 linux-5h2s systemd[1]: Started Samba SMB Daemon.
Aug 27 14:29:47 linux-5h2s smbd[3199]: [2017/08/27 14:29:47.085767,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Aug 27 14:29:47 linux-5h2s smbd[3199]:   STATUS=daemon 'smbd' finished starting up and ready to serve connections

Code:
# systemctl status nmb
● nmb.service - Samba NMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2017-08-27 19:45:30 CEST; 28min ago
 Main PID: 16318 (nmbd)
   Status: "nmbd: ready to serve connections..."
    Tasks: 1 (limit: 512)
   CGroup: /system.slice/nmb.service
           └─16318 /usr/sbin/nmbd -D

Aug 27 19:45:30 linux-5h2s systemd[1]: Starting Samba NMB Daemon...
Aug 27 19:45:30 linux-5h2s systemd[1]: nmb.service: Supervising process 16318 which is not our child. We'll most likely not notice when it exits.
Aug 27 19:45:30 linux-5h2s systemd[1]: Started Samba NMB Daemon.
Aug 27 19:45:30 linux-5h2s nmbd[16318]: [2017/08/27 19:45:30.118554,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Aug 27 19:45:30 linux-5h2s nmbd[16318]:   STATUS=daemon 'nmbd' finished starting up and ready to serve connections

Code:
# smbclient -L localhost
Enter HOMENET\root's password: 
Domain=[LINUX-5H2S] OS=[] Server=[]

        Sharename       Type      Comment
        ---------       ----      -------
        Netzwerkspeicher Disk      Familien-Laufwerk
        IPC$            IPC       IPC Service (Samba 4.6.5-git.32.af7a173b7a11.1-SUSE-SLE_12-x86_64)
        root            Disk      Persönliches Laufwerk
Domain=[LINUX-5H2S] OS=[] Server=[]

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------
        HOMENET              FRITZ-NAS

Code:
# smbstatus

Samba version 4.6.5-git.32.af7a173b7a11.1-SUSE-SLE_12-x86_64
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
8837    mike         users        192.168.178.20 (ipv4:192.168.178.20:49155) SMB2_10           -                    -                    
15433   conna        users        192.168.178.27 (ipv4:192.168.178.27:49159) SMB2_10           -                    -                    

Service      pid     Machine       Connected at                     Encryption   Signing     
---------------------------------------------------------------------------------------------
Netzwerkspeicher 15433   192.168.178.27 Sun Aug 27 19:40:29 2017 CEST    -            -           
mike         8837    192.168.178.20 Sun Aug 27 15:04:38 2017 CEST    -            -           
Netzwerkspeicher 8837    192.168.178.20 Sun Aug 27 15:04:38 2017 CEST    -            -           
conna        15433   192.168.178.27 Sun Aug 27 19:40:29 2017 CEST    -            -           

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
8837         1002       DENY_ALL   0x100080    RDONLY     NONE             /srv/data/public   .   Sun Aug 27 19:42:18 2017
8837         1000       DENY_NONE  0x100080    RDONLY     NONE             /srv/data/private/mike   .   Sun Aug 27 19:55:31 2017

Gruß, Hengstenberg
 
OP
Hengstenberg

Hengstenberg

Member
Ja, die Windows-User existieren als User auf dem Samba-Server und sind in /etc/samba/smbusers definiert:
Code:
root = administrator
mike = "Michael Hengstenberg"
conna = "Cornelia Hengstenberg"

In der /etc/samba/smb.conf ist im [global]-Block
Code:
username map = /etc/samba/smbusers
enthalten.

Per (beispielhaft für User mike)
Code:
# smbpasswd -a mike
wurden damals auch Samba-Passwörter zugewiesen.
 
OP
Hengstenberg

Hengstenberg

Member
@ spoensche:
Ja, die User gibt es auch auf dem System.


Ich habe etwas herumexperimentiert. Und was mir schon beim ersten Aufsetzen des Samba-Servers aufgefallen ist, dass Änderungen, die ich in den smb.conf mache, nicht "vollständig" übernommen werden. Ein Beispiel:

Der [Netzwerkspeicher]-Block sieht aktuell so aus (und funktioniert so auch einwandfrei):
Code:
[Netzwerkspeicher]
	comment = Familien-Laufwerk
	path = /srv/data/public
	read only = No
	force create mode = 0664
	force directory mode = 0775
	force user = chief
	force group = users
	inherit acls = Yes
In meinem Linux-Buch (also so richtig aus Papier) habe ich nun eine Option gesehen, die ich besser finde, so dass ich statt der beiden Einträge
Code:
	force user = chief
	force group = users
folgenden Eintrag gemacht habe:
Code:
	valid users = @users
So sollten also mike und conna, die beide Mitglieder der Gruppe users sind, auf die gemeinsame Ressource zugreifen und schreiben können und dabei Einträge hinterlassen, die auf deren UID hören aber dennoch beschreibbar sind für alle anderen Mitglieder der Gruppe users.
Lange Rede: Macht er nicht!

Erst nach dem ich folgenden neuen Block erstellt habe
Code:
[Gruppenspeicher]
	comment = alternatives Familien-Laufwerk
	path = /srv/data/public
	read only = No
	force create mode = 0664
	force directory mode = 0775
	valid users = @users
	inherit acls = Yes
erhalte ich das gewünschte Verhalten!

Muss man ggf. den Samba-Server nach jeder Änderung in der smb.conf neustarten oder so etwas?
 
OP
Hengstenberg

Hengstenberg

Member
Liebe Community,

"finally", habe ich keine Lösung gefunden aber einen Workaround, damit der individuelle Zugriff auf den in einem [homes]-Block definierten Zugang funktioniert. Allerdings musste ich eine Konfiguration anwenden, die mir nicht gefällt, aber erst mal funktioniert.

So sieht also nun die aktuelle /etc/samba/smb.conf aus:
Code:
[global]
	workgroup = HOMENET
	passdb backend = tdbsam
	map to guest = Bad User
	security = user
	username map = /etc/samba/smbusers
	domain master = Yes
	preferred master = Yes

[homes]
	comment = Persönliches Laufwerk
	path = /srv/data/private/%S
	browseable = No
	read only = No
	force create mode = 0640
	force directory mode = 0750
	inherit acls = Yes

[Micha_data]
	comment = Michas data-Laufwerk
	path = /srv/data/private/mike
	browseable = No
	read only = No
	valid users = mike
	inherit acls = Yes

[Conna_data]
	comment = Connas data-Laufwerk
	path = /srv/data/private/conna
	browseable = No
	read only = No
	valid users = conna
	inherit acls = Yes

[Netzwerkspeicher]
	comment = Familien-Laufwerk
	path = /srv/data/public
	read only = No
	force create mode = 0664
	force directory mode = 0775
	valid users = @users
	inherit acls = Yes
Mein Workaround sieht nun also vor, dass ich individuelle Blöcke für jeden Windows-User erstelle (hier: [Micha_data] und [Conna_data]), diese aber per browseable = No auf den Windows-Clients nicht sichtbar mache. Hat den Vorteil, dass die jeweiligen anderen Windows-User nicht die anderen Freigaben sehen (aber eben der "berechtigte" Windows-User seine Freigabe auch nicht). Den [homes]-Block belasse ich fast unverändert und nutze hier seine Funktionalität, dass dieser abhängig vom Windows-Nutzer nur dessen Freigabe anzeigt. Auf diese Weise erlangt jeder Windows-User nun wieder Zugriff auf sein persönliches Laufwerk. Aber wie beschrieben, ohne die Blöcke [Micha_data] und [Conna_data] funktioniert der Zugriff nur über den [homes]-Block bei mir derzeit nicht.

Unglücklich bin ich dennoch mit dieser "Lösung", da es nicht Sinn und Zweck ist, Samba so zu konfigurieren. Deshalb bin ich auf weitere Hinweise und Lösungsvorschläge gespannt, um dieses Thema von [workaround] nach [gelöst] zu markieren.

Grüße, Hengstenberg
 

spoensche

Moderator
Teammitglied
Also im Samba Wiki ist in der Introduction erklärt, warum man [homes] nicht mehr nutzen sollte und das evtl. ein Workaround nötig ist.

https://wiki.samba.org/index.php/User_Home_Folders#Introduction
 
Oben