Samba stört Msheimnetz

badpitt · 19. März 2016

Hallo Forum,
ich will mir selber ein NAS bauen und habe dafür einen OpenWRT-Router mit einer externen HDD verbunden. Jetzt will ich bestimmte Ordner per Samba im Netzwerk freigeben. Leider klappt das nicht: Wenn ich per Windows oder Linux von einem anderen Rechner auf Msheimnetz zugreifen will, wird sofort ein Passwort verlangt. Dabei sind unter dieser Gruppe auch immer Shares anderer Computer gelistet! Das Openwrt wirkt hier also eindeutig störend.

Der Internetrouter hat die lokale Adresse 192.168.0.1, der "neue NAS-Router" 192.168.1.1. Ich möchte diese Adresse unbedingt so lassen, weil das die Standardadresse des Openwrt-Routers ist. Im Fehlerfall ist die immer erreichbar (Änderung=Brick-Gefahr). Vielleicht hängt mein Problem mit den zwei verschiedenen Subnetzen zusammen. Hab im Hauptrouter schon die Subnetzmaske auf 255.255.0.0 geändert, sodass sich beide Netze eigentlich sehen können.

OpenWrt hat keine gewöhnliche smb.conf, sondern erstellt sie automatisch, nach Einstellung über die Weboberfläche Luci. Die benutzt eine editierbare Vorlage für die smb.conf. Begriffe, die mit | beginnen und enden, werden von der Software ersetzt. Das sieht dann so aus:

Code:

[global]
	netbios name = |NAME| 
	display charset = |CHARSET|
	interfaces = |INTERFACES|192.168.0.1/16
	server string = |DESCRIPTION|
	unix charset = |CHARSET|
	workgroup = |WORKGROUP|
	browseable = yes
	deadtime = 30
	domain master = yes
	encrypt passwords = true
	enable core files = no
	guest account = nobody
	guest ok = yes
	invalid users = root
	local master = yes
	load printers = no
	map to guest = Bad User
	max protocol = SMB2
	min receivefile size = 16384
	null passwords = yes
	obey pam restrictions = yes
	os level = 20
	passdb backend = smbpasswd
	preferred master = yes
	printable = no
	security = share
	smb encrypt = disabled
	smb passwd file = /etc/samba/smbpasswd
	socket options = TCP_NODELAY IPTOS_LOWDELAY
	syslog = 2
	use sendfile = yes
	writeable = yes

In der Zeile interfaces = |INTERFACES|192.168.0.1/16 habe ich (wie man sehen kann) mal probeweise den Adressraum des Heimnetzes angehängt. Der fehlte in der resultierenden smb.conf. Dadurch funktioniert der Zugriff auf Msheimnetz jetzt zwar wieder auf allen Computern, aber der NAS taucht da nicht auf.

Die resultierende smb.conf sieht dann wie folgt aus. Die Sicherheitseinstellungen sollten eigentlich okay sein. Woran kann es liegen, dass das Windows-Netzwerk gestört wird und passwortfreie Shares nicht möglich sind?

Code:

[global]
        netbios name = Mein_NAS
        display charset = UTF-8
        interfaces = 127.0.0.1/8 lo 192.168.1.1/16 br-lan 192.168.0.1/16
        server string = Netzwerk-Festplatte
        unix charset = UTF-8
        workgroup = MSHEIMNETZ
        browseable = yes
        deadtime = 30
        domain master = yes
        encrypt passwords = true
        enable core files = no
        guest account = nobody
        guest ok = yes
        invalid users = root
        local master = yes
        load printers = no
        map to guest = Bad User
        max protocol = SMB2
  encrypt passwords = true
        enable core files = no
        guest account = nobody
        guest ok = yes
        invalid users = root
        local master = yes
        load printers = no
        map to guest = Bad User
        max protocol = SMB2
        min receivefile size = 16384
        null passwords = yes
        obey pam restrictions = yes
        os level = 20
        passdb backend = smbpasswd
        preferred master = yes
        printable = no
        security = share
        smb encrypt = disabled
        smb passwd file = /etc/samba/smbpasswd
  null passwords = yes
        obey pam restrictions = yes
        os level = 20
        passdb backend = smbpasswd
        preferred master = yes
        printable = no
        security = share
        smb encrypt = disabled
        smb passwd file = /etc/samba/smbpasswd
        socket options = TCP_NODELAY IPTOS_LOWDELAY
        syslog = 2
        use sendfile = yes
        writeable = yes
[homes]
        comment     = Home Directories
        browsable   = no
        read only   = no
        create mode = 0750


[Aufnahmen]
        path = /Backup_Festplattenarray/Videos/Aufnahmen
        read only = no
        guest ok = yes
        create mask = 777
        directory mask = 777

[writeable]
        path = /Backup_Festplattenarray/Isos/writeable
        read only = no
        guest ok = yes
        create mask = 777
        directory mask = 777

thebackfisch · 19. März 2016

Die Netzwerkkonfiguration muss natürlich stimmen. Du hast also zwei Router? der eine mit 0.1 und der andere 1.1? Beide müssen natürlich dann die Subnetzmaske 255.255.0.0 haben, bzw /16. Auch alle anderen Netzwerkteilnehmer brauchen diese Einstellungen, überprüfe das mal auf den PCs.

Als Interface 192.168.0.1/16 hinzuzufügen ist quatsch, da ein solches Interface auf diesem Router doch gar nicht existiert (oder doch?).

Versuche mal bei der Freigabe [Aufnamen] folgendes hinzuzufügen:

Code:

public = yes
only guest = yes

Die Freigaben für die Homeverzeichnisse würde ich entfernen. Auch kann helfen, den security-parameter auf "user" zu stellen:

Code:

security = user

blöderidiot · 19. März 2016

domain master = no

badpitt · 19. März 2016

Vielen Dank schonmal für die wahnsinnig schnelle Antwort.

Code:

domain master = no

hat ein kleines Wunder bewirkt: Msheimnetz kann jetzt wieder geöffnet werden und das neue NAS ist auch gelistet, leider immernoch ohne Zugriffsmöglichkeit (Access denied). Immerhin gehen die anderen Shares der anderen Computer jetzt wieder!

Du hast also zwei Router? der eine mit 0.1 und der andere 1.1? Beide müssen natürlich dann die Subnetzmaske 255.255.0.0 haben

Ja genau. Hab die Subnetzmaske bei beiden eingetragen. 1.1 ist der neue NAS und hat eine statische IP-Adresse. DHCP ist dort abgeschaltet und als DNS hab ich den Hauptrouter 0.1 angegeben, was soweit zu funktionieren scheint.

Im Hauptrouter (0.1) läuft ein DHCP-Server, bei dem ich vorsichtshalber 1.1 auch nocheinmal als feste Adresse für den NAS reserviert habe. Alle anderen Adressen werden nach dem Schema 192.168.0.x vergeben. Die Ausnahme, 1.1 für das NAS konnte ich da auch erst einstellen, nachdem ich die Subnetzmaske auf 255.255.0.0 geändert hatte. Vorher ging das gar nicht.

Als Interface 192.168.0.1/16 hinzuzufügen ist quatsch, da ein solches Interface auf diesem Router doch gar nicht existiert (oder doch?).

Das hinzugefügte Interface habe ich jetzt wieder entfernt, was sicher zu dem positiven Ergebnis beigetragen hat.

Bei den Freigaben kann ich leider keine Optionen hinzufügen, weil Änderungen an der smb.conf sofort wieder automatisch entfernt werden. Diese Luci-Weboberfläche macht das. Da gibt es zwar das erwähnte Template (ich hatte sie Vorlage genannt), doch gerade die Shares können dort nicht bearbeitet werdn. Die werden per Mausklicks und Pfadangaben in dem Frontend eingestellt. Die zugehörigen Zeilen schreibt Luci dann automatisch in die smb.conf.

Code:

Die Freigaben für die Homeverzeichnisse würde ich entfernen.

oh, gut, dass Du das erwähnst: Die Option verstehe ich nämlich nicht. Openwrt hat nur einen Nutzer, nämlich root. In der Weboberfläche kann man einen Wert eintippen für die Option "Heimatverzeichnisse freigeben". Voreinsgestellt ist "1". Als Anmerkung steht daneben: "Systembenutzer dürfen ihre Heimatverzeichnis über Netzwerkfreigaben erreichen."
Bestimmt hat das was mit der von Dir erwähnten Einstellung zu tun. Hab im Netz nichts zu der Luci-Funktion finden können.

Code:

security = user

war voreingestellt. Auf diversen Webseiten wurde empfohlen, die Option auf share zu stellen, um das Sicherheitslevel zu senken. Ich stell' es mal wieder zurück und gucke was passiert.

Für weitere Vorschläge, um jetzt auch noch dieses "Access denied" loszuwerden, wäre ich dankbar.

Ergänzung (19. März 2016)

Keine Änderrung der Situation mit security = user.

Edit 2:

Ich verzweifle hier langsam. Hab jetzt so viel durchgelesen und ausprobiert...ich finde einfach keinen Fehler. Die ganzen Anleitungen im Netz beschreiben das genauso wie ich es gemacht habe. Hab jetzt sogar nen neuen samab-user angelegt, ohne Passwort und den als guest-account genommen - kein Erfolg. Hab user nobody ein leeres Passwort verpasst - alles wie immer. Diverse Befehle von der smb.conf-manpage durchprobiert - Keine Änderung des Problems.

Hier meine neueste smb.conf-Vorlage, nachdem ich mit Werten rumprobiert habe:

Code:

[global]
	netbios name = |NAME| 
	display charset = |CHARSET|
	interfaces = |INTERFACES|
	server string = |DESCRIPTION|
	unix charset = |CHARSET|
	workgroup = |WORKGROUP|
	browseable = yes
	deadtime = 30
	domain master = no
	encrypt passwords = true
	enable core files = no
	guest account = nobody
	guest ok = yes
	invalid users = root
	local master = yes
	load printers = yes
	map to guest = Bad Password
	max protocol = NT1
	min receivefile size = 16384
	null passwords = yes
	obey pam restrictions = yes
	os level = 20
	passdb backend = smbpasswd
	preferred master = no
	printable = no
	security = user
	smb encrypt = disabled
	smb passwd file = /etc/samba/smbpasswd
	socket options = TCP_NODELAY IPTOS_LOWDELAY
	syslog = 2
	use sendfile = yes
	writeable = yes
	restrict anonymous = 0

blöderidiot · 20. März 2016

Bei security=user sollest Du auf dem NAS einen user mit dem selben Namen und dem selben Passwort wie unter Windows anlegen.

# smbpasswd -a badpitt

badpitt · 20. März 2016

Welches Windows? Jeder Rechner hier hat ein anderes OS, mit anderen Usern. Zu allem Überfluss können unter Openwrt außer root keine weiteren User angelegt werden. Im Samba natürlich schon. Es gibt zwei User für Gastzwecke: Badpitt und nobody, beide mit leerem Passwort. Beide habe ich in der conf-datei von Samba ausprobiert.

Mittlerweile glaube ich an ein Netzwerkproblem. Habe erstmal Samba neu installiert. In den OpenWrt-Repos gab es tatsächlich eine neuere Version 3.25-1. Updates sind da sonst eigentlich selten. Keine Änderung des Problems.

Dann habe ich den OpenWrt-Router doch in's andere Netz geholt und ihm eine neue IP-Verpasst, also 192.168.0.111. Keine Änderung des Problems. Dann habe ich versucht, Samba mit Wins-Server zu betreiben, immernoch kein Fortschritt. Zwischendurch fiel mir auf, dass die Firewall von Openwrt ja gar keine Ausnahmen für Samba / Netbios hat. Hab also da dann Ports freigegeben: 137 und 138 (UDP), 139 (TCP) und 445 (TCP) für eingehende Verbindungen und Weiterleitungen. Hab die Regeln vorne in die Liste gesetzt, damit sie auf jeden Fall wirksam sind.

Trotzdem keine Verbesserung der Situation. Die Ports und Protokolle sind von der OpenWrt-Seite. Gerade habe ich eine andere Seite gefunden, die weitere Ports und andere Protokolle angibt. Vielleicht sollte ich die auch noch mal probieren.

Die Ports sind diese:

netbios-ns – 137/tcp # NETBIOS Name Service
netbios-dgm – 138/tcp # NETBIOS Datagram Service
netbios-ssn – 139/tcp # NETBIOS session service
microsoft-ds – 445/tcp # if you are using Active Directory

Other ports:

Port 389 (TCP) – for LDAP (Active Directory Mode)
Port 445 (TCP) – NetBIOS was moved to 445 after 2000 and beyond, (CIFS)
Port 901 (TCP) – for SWAT service (not related to client communication)

Leider ändert sich auch mit diesen Einstellungen nichts am Problem. Habe allerdings nur die Ports für Verbindungen zwischen LAN und OpenWRT-Router freigegeben. Nicht LAN-LAN-Verbindungen. Welche werden denn überhaupt gebrauch?

Ergänzung (20. März 2016)

Heureka!
Das war ja 'ne Geburt!
Ich hab's endlich geschafft. Wie es aussieht, braucht Samba doch einen User im Linux-System. Dabei wird doch in allen Anleitungen etwas anders behauptet. Das Anlegen eines Nutzers im Samba reicht nicht.

Da OpenWrt das Anlegen von Nutzern nicht erlaubt, muss erst was installiert werden, damit es doch geht. Anleitung hier.

Installiert werden müssen shadow-useradd und sudo:

Code:

opkg update
opkg install shadow-useradd
opkg install sudo

dann müssen diverse Dateien angepasst werden: /etc/passwd, /etc/group, /etc/shadow und natürlich sudoers mit dem Befehl visudo.

Ein User wird mit

Code:

useradd badpitt

hinzugefügt.
Ein leeres Passwort für diesen Nutzer wird mit

Code:

passwd badpitt

und zweimaligem Enter-Druck erstellt.
Es ist jedoch wichtig, dass der neue und einzige Nutzer die ID 1000 erhält, weil das die Standard-ID ist und die vorhandenen Ordner auf der Festplatte alle mit dieser ID erstellt wurden. Bekommt der neue Nutzer eine andere ID-Nummer, kann er später nicht oder nicht richtig auf die Ordner und Dateien zugreifen. Deshalb muss man die erwähnten Config-Dateien im Ordner /etc/ alle nocheinmal von Hand nachbearbeiten.
Wichtig auch: In den Dateien darf kein Nutzer doppelt vorkommen. Die Datei /etc/passwd muss ferner in der Zeile für den Nutzer mit /bin/ash enden, damit sich der neue Nutzer einloggen kann. Das steht aber auch alles auf der verlinkten Seite.

Schema der Nutzerzeile in /etc/passwd:

Code:

badpitt:x:1000:1000:badpitt:/home/badpitt:/bin/ash

Der in der Zeile erwähnte Home-Ordner muss natürlich ebenfalls von Hand erstellt werden:

Code:

mkdir -p /home/badpitt
chown badpitt /home/badpitt
chgrp /home/badpitt
chmod ugo=rwx /home/badpitt

Außerdem muss es möglich sein, Sudo auszuführen, wenn man als Nutzer eingeloggt ist. Der Befehl visudo bearbeitet die entsprechende Datei. Man muss die Raute in zwei Zeilen entfernen, um sie zu aktivieren, so wie hier:

Code:

## Uncomment to allow any user to run sudo if they know the password         
## of the user they are running the command as (root by default).            
Defaults targetpw  # Ask for the password of the target user                 
ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

Der blöde Editor erlaubt nur die Entf-Taste zum Löschen. Geblättert wird mit Bild-auf und Bild-ab Tasten. Speichern und Ende wird ausgelöst mit Druck auf Esc-Taste und zweimal ZZ (ja, Großbuchstaben).

In der Vorlage für smb.conf gehört (in der Luci Weboberfläche) noch die Zeile:

Code:

guest account = nobody

in

Code:

guest account = badpitt

geändert, weil badpitt jetzt der neue Gast-Account ist. Wichtig: Nocheinmal prüfen, ob alle freigegebenen Ordner auch wirklich diesem Nutzer gehören und er auch Lese- und Schreibrechte hat.

das geht mit

Code:

ls -la /Ordnername

Die Firewall-Regeln waren bestimmt auch nötig, um Samba den Netzverkehr zu erlauben. Hab inzwischen auch die erwähnten zusätzlichen Ports für Verkehr von LAN in LAN freigegeben. Alle Regeln stehen in der Firewall Liste oben, direkt unter "Allow DHCP Renew" und "Ping". Hab gelesen, dass das wichtig sei, damit andere Einträge die neuen Regeln nicht verhindern. Die Liste wird von der Firewall wohl von oben nach unten ausgewertet. Die Ports hießen:

137,138,139,389,445,901

hab einfach für alle Ports beidies freigegeben, TCP und UDP, allerdings nur für Verkehr innerhalb des Netzes und vom LAN in den Router.

Ich hoffe, andere mit dem gleichen Problem können meine Lösung brauchen. Vielen Dank für die hilfreichen Antworten.

Meine smb.conf-Vorlage im Luci schaut jetzt so aus:

Code:

[global]
	netbios name = |NAME| 
	display charset = |CHARSET|
	interfaces = |INTERFACES|
	server string = |DESCRIPTION|
	unix charset = |CHARSET|
	workgroup = |WORKGROUP|
	browseable = yes
	deadtime = 30
	domain master = no
	encrypt passwords = true
	enable core files = no
	guest account = badpitt
	guest ok = yes
	invalid users = root
	local master = yes
	load printers = yes
	map to guest = Bad User
	max protocol = NT1
	min receivefile size = 16384
	null passwords = yes
	obey pam restrictions = yes
	os level = 20
	passdb backend = smbpasswd
	preferred master = no
	printable = no
	security = user
	smb encrypt = disabled
	smb passwd file = /etc/samba/smbpasswd
	socket options = TCP_NODELAY IPTOS_LOWDELAY
	syslog = 2
	use sendfile = yes
	writeable = yes
	restrict anonymous = 0

Einige Tweaks sind darin von mir vorgenommen worden:

Code:

max protocol = NT1

sorgt dafür, dass höchstens das SMB-Protokoll von WinXP und nicht etwa von Vista, win7 oder 8 verwendet wird. Das müssten eigentlich alle Clients beherrschen.

Code:

restrict anonymous = 0

Erlaubt nocheinmal zusätzlich explizit anonymen Zugriff.

Code:

map to guest = Bad User

ist genau wie vorher, könnte aber auch in

Code:

map to guest = Bad Password

geändert werden und würde dann bewirken, dass eine falsche Passworteingabe eine Weiterleitung zum Gast-Account bewirkt, statt die Eingabe eines falschen Nutzernamens.

Code:

use sendfile = yes

Soll die Datenübertragungsgeschwindigkeit erhöhen, kann aber auch verlangsamend wirken, wenn die CPU des Routers zu schwach ist. Muss ich also selbst noch ausprobieren.

Kann man hier irgendwo einen Threat als [gelöst] markieren? Ich find' gerade nichts in der Richtung.

Suche

Samba stört Msheimnetz

badpitt

Cadet 4th Year

thebackfisch

Ensign

blöderidiot

Captain

badpitt

Cadet 4th Year

blöderidiot

Captain

badpitt

Cadet 4th Year

Ähnliche Themen