Beiträge von Suelkun

Zitat von neptun

Unter Suse 12 brauchte man nur mit smbpasswd -a user den Gastzugang löschen,
so das man nur noch mit Anmeldung unter Windows 7 eine Samba Verbindung öffnen konnte.

Leider wurde unter Samba 4.1 (Suse13.1) irgendwas geändert, ich komme einfach über Windows auf
das Samba Verzeichnis ohne Anmeldung rauf.

Mein Linux-User habe ich mit smbpasswd -a einen Passwort zugewiesen
smb.conf

Code

workgroup = WORKGROUP 
passdb backend = tdbsam 
printing = cups 
printcap name = cups 
printcap cache time = 750 
cups options = raw 
map to guest = Bad User 
include = /etc/samba/dhcp.conf 
logon path = \\%L\profiles\.msprofile 
logon home = \\%L\%U\.9xprofile 
logon drive = P: 
usershare allow guests = Yes 


# Ab hier habe ich alle Zeilen ergänzt, aber ohne Erfolgt 
bind interfaces only = yes 
interfaces = enp2s0 
security = user 
encrypt passwords = true 
invalid users = root 
public = no 
guest ok = no

Alles anzeigen

Leider bring alles nicht, ich komme ohne User & PW Abfrage über Windows rauf

Was mache ich falsch?

Betr. Shell Installation

Alles anzeigen

Wieso dann
usershare allow guests = yes ?

Zitat von Trekkie00

Reicht es denn nicht aus die betreffenden Ports in der Firewall freizugeben?

...das würde natürlich auch ausreichen.

Ich habe aber eine Hardware-Firewall außerhalb des Rechners, die für das gesamte Hausnetz da ist. Deshalb habe ich unter Linux immer die FW abgeschaltet (bis auf 13.1, wo ich es vergessen habe).:(

Nun gut, das Problem ist gelöst:

Wie meist sitzt das Problem vor und nicht im Rechner.

Um es kurz zu machen: Samba ist völlig unschuldig. Aus welchen Gründen auch immer habe ich die Firewall von 13.1 eingeschaltet gehabt und dadurch hat die Firewall jeden Versuch des Verbindungsaufbaus eines Clients verhindert.
Nach Abschalten der Firewall lief Samba sofort und ich konnte die Shares einwandfrei verbinden.

Na, ja,

die Zeile

net.ipv6.conf.all.disable_ipv6 = 1

hatte ich schon seit 2-3 Tagen in der Datei /etc/sysctl.conf stehen. Dies scheint aber samba mitnichten daran zu hindern, auf IPV6 ports zu hören. Jedenfalls habe ich unter Samba 3.x 2 Ports, auf die Samba hört und unter Samba 4.1 habe ich deren 4.
Abstellen kann ich das Hören auf 4 Ports nur, indem ich in die globale section von smb.conf die Zeilen

nterface = 192.168.0.11 127.0.0.1  	#  mit 192.168.0.11 =  IP des Servers 
bind interfaces only = yes         	#

einfüge. Ich weiß aber nicht, was das sonst an Nebenwirkungen hat. Shares von Win7 Clients her einbinden konnte ich in dieser Konfiguration auch nicht.
Wenn ich z.B. die Zeile

Interface = 0.0.0.0  	
bind interfaces only = yes

in die globale section von smb.conf einfuege (damit würde ich dem ziemlich nahe kommen, was lt. netstat samba 3.x tut), dann bleibt der Befehl

systemctl restart nmd.service

hängen.

Zitat von Flytronik

Zitat von grossing

Die Rechte des Verzeichnisses wollen auch mal angeschaut werden...

und natürlich sicherstellen, daß Verzeichnis und Datei existieren.

Wobei das auch beachtet werden will:

Code

Aug 22 13:30:22 Mozart kernel: type=1400 audit(1408707022.184:52): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/smbd" name="/var/run/samba/locks/messages.tdb" pid=9359 comm="smbd" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0

Evtl. doch AppArmor.

flo

Alles anzeigen

Also:
An Samba hat sich von 3.x auf 4.x in der Tat eine Menge geändert.

In der Zwischenzeit habe ich die Datei smb.conf umgearbeitet, die neue Konfigurationsdatei im Anhang.
Ich habe so lange logprof aufgrufen und (AppArmor-)Profile (für smbd und nmbd gespeichert, bis keine Meldungen mehr kamen.
Wo Verzeichnisse gefehlt haben, habe ich diese eingerichtet.
IPv6 habe ich (für die Netzwerkkarte) abgeschaltet.

Funktionieren tut es leider immer noch nicht, d.h. ein Win7-Client kann einfach keine Share verbinden, die SuSE anbieten sollte. Ich sehe den Linux-Rechner auch nicht in der Netzwerkumgebung von Windows7.

netstat liefert folgende Ergebnisse:

netstat -tulpn | grep mbd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 5897/smbd 
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 5897/smbd 
tcp 0 0 :::445 :::* LISTEN 5897/smbd 
tcp 0 0 :::139 :::* LISTEN 5897/smbd 
udp 0 0 192.168.0.255:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.0.11:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.85.255:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.85.1:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.213.255:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.213.1:137 0.0.0.0:* 5878/nmbd 
udp 0 0 0.0.0.0:137 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.0.255:138 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.0.11:138 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.85.255:138 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.85.1:138 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.213.255:138 0.0.0.0:* 5878/nmbd 
udp 0 0 192.168.213.1:138 0.0.0.0:* 5878/nmbd 
udp 0 0 0.0.0.0:138 0.0.0.0:* 5878/nmbd

Ich gewinne den Eindruck, daß es nun daran liegt, daß Samba auf IPv4 und IPv6 lauscht. Kann das der Fehler sein? Allerdings konnte ich auch keine Shares an WIN7-Clients verbinden, als ich den globalen Parameter interfaces auf die lokale IP4-Adresse des Servers und dessen localhost Pendant gesetzt habe und zusätzlich den globalen Parameter bind interfaces only = yes gesetzt habe.

Kann man per Parameter irgendwie IPv6 abschalten?

Zitat von Sauerland

apparmor als Quelle ausgeschlossen?

Nein, genau daran liegt es aber.

Samba funktioniert zwar immer noch nicht, es liegt aber definitiv nicht an Samba selbst.
Apparmor ist ja neu im Spiel und ich habe deshalb keine Erfahrung damit. Muß wohl ein wenig damit rumspielen.
Vielleicht bekomme ich es ja hin. Ich melde mich jedenfalls, wenn ich die Lösung habe.

...gerne

a) ich habe smbpasswd schon draußen. Die log-Datei enthält einige Versuche, Samba zu starten. Im Zuge meiner Versuche habe ich auch den von Dir bemängelten Eintrag korrigiert. Wenn es hilft, mache ich auch noch eine ganz frische log-Datei, daran soll es nicht liegen.

b) Output von systemctl und journalctl im Anhang als screenshot, bzw. Textdatei

c) die aktuelle smb.conf-Datei im Anhang

Hallo,

ich benutze seit vielen Jahren openSuSE mit Samba als Server und verschiedene virtuelle Win-Maschinen als Clients, die dann Daten über Samba-Freigaben auf Linux ablegen bzw lesen.
Das alles funktioniert ebenso seit Jahren völlig problemlos.

Bisher setze ich openSuSE 12.3 ein und bin eben dabei, die gesamte Konfiguration auf 13.1 umzustellen.

Dazu habe ich neben der laufenden 12.3 - Konfiguration eine eigene 13.1 Installation, bei der ich alle benötigten Services nach und nach hochziehe. Wenn alles funktioniert, dann werde ich auf 13.1 umschwenken.

Mit Samba habe ich nun ein Problem, dem ich beim besten Willen nicht beikomme: Der Service nmb startet problemlos, wohingegen der Service smb sich nicht starten läßt (weder über systemctl noch über Yast)

Ich habe die Samba-Konfigurationsdateien (d.h. den Inhalt des Ordners /etc/samba/ ) von 12.3 auf 13.1 (gleicher Ordner) kopiert. Beim Start bringt dann Samba unter /var/log/samba/log.smbd die Meldungen lt. angehängter Datei.

Darin beschwert sich Samba über fehlende Zugriffsberechtigung der Datei /var/run/samba/locks/messages.tdb.

Diese Datei hat Lese- und Schreibrechte für root und ich will Samba auch nur unter root starten. Selbst wenn ich der Datei volle Zugriffsrechte für alle gebe, kommt die Meldung.

Der Aufruf testparm bringt für meine smb.conf keine Fehler. Momentan weiß ich nicht, wie ich weiterkomme. Hat jemand dieses Problem schon einmal gehabt und wie sah die Lösung aus?

Das Problem ist gelöst. Die Lösung brachte der unten zitierte Beitrag mit gleicher Problemstellung.

Zitat von linov

/usr/lib/systemd/system/backup.service:

[Unit]
Description=backup service
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/etc/init.d/backup.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Alles anzeigen

Entscheidend war, daß ich ja nicht unbedingt genau bis zu einem wohldefinierten Zeitpunkt warten mußte, bis mein Backupscript ausgeführt wird. Es war ausreichend, daß mein Script irgendwann mal während des Runterfahrens ausgeführt wird. Genau das lieferte der og. Beitrag und er funktioniert bei mir auch.

Hallo,

vor ein paar Tagen habe ich mich dazu entschlossen, openSuse 12.3 produktiv einzusetzen. Vorher habe ich openSuse 12.2 benutzt.

Ich benutze sowohl ein eigenes Startfile /etc/init.d/boot.local als auch ein eigenes File /etc/init.d/halt.local. Im ersten werden ein paar (manchmal notwendige) Aufräumarbeiten gemacht, die von einer vorigen Session ggf. übriggeblieben sind, im letzteren will ich Datensicherungsarbeiten durchführen (kopieren wichtiger Dateien auf eine zweite Platte,...).

Das Startfile wird immer und richtig ausgeführt. Dies ohne jede Änderung meinerseits beim Startprozess.

Die Behandlung der Datei /etc/init.d/halt-local macht allerdings schon Schwierigkeiten. Das heißt: sie wird einfach nicht ausgeführt.

Es ist mir klar, daß openSuse seit Version 12.x systemd benutzt. Es ist mir auch klar, daß es ein serviceFile geben muß, welches systemd dazu veranlaßt, /etc/init.d/halt-local auszuführen. Unter 12.2 habe ich dazu ein eigenes ServiceFile geschrieben, welches bis zu den letzten Systemupdates (für 12.2) funktioniert hat. Ich mußte es zwar nach gewissen Systemupdates immer wieder anwerfen, aber wenn es dann einmal lief, dann lief es bis zum nächsten Systemupdate. Ab einem bestimmten Punkt aber habe ich mein Servicefile unter 12.2 nicht mehr zum funktionieren gebracht. Nachdem ich ohnehin auf 12.3 umstellen wollte, habe ich das Problem dann bis zur Umstellung zurückgestellt.

Nun bekomme ich mein halt-local-file unter 12.3 auch nicht zum Laufen.

Ich habe festgestellt, daß es ein zugehöriges service-File im Verzeichnis /usr/lib/systemd/system/ gibt
(Name: halt-local.service), welches genau das tut, was ich will: Es startet das Script /etc/init.d/halt-local.
Dieses Service File wird mit der Distribution mitgeliefert.

Aber: das Service File enthält keine Sektion [Install].

Das wiederum bedeutet, daß der Befehl: "systemctl enable halt-local.service" scheitert.

Ich habe irgendwo gelesen, daß service-files ohne Sektion [Install] eben von anderen (bereits installierten) Services referenziert werden.

Meine Frage jetzt: Was habe ich zu tun, damit halt-local.service bei shutdown dann wirklich benutzt wird?

Für Hilfe wäre ich sehr dankbar, weil ich schon ziemlich viel Zeit ohne erkennbaren Erfolg investiert habe.