Samba Shares funktion seit Update auf UCS 4.1.0

Hallo,

ich habe seit dem Update auf UCS 4.1.0 auf fast allen Windows Systemen Probleme auf Shares der Samba Fileserver zuzugreifen. Einzig ein Windows 2008 Server kann noch SMB Shares öffnen.
Ein Versuch die Fileserver erneut zu installieren schlägt fehl. Auch ein neu installierter Fileserver mit und ohne Updates löst das Problem nicht. Eine Neuinstallation der Clients führt ebenfalls nicht zum Erfolg.

Nach mehreren Versuchen erscheint mir der Samba4 DomainController das Problem zu verursachen. Stelle ich in einer Testumgebung den alten DC wieder her kann ich auf die Shares zugreifen. Sofort nach dem Update auf UCS 4.1.0 funktioniert der Zugriff dann wieder nicht.

Die Fehlermeldung die ich erhalte lautet wie folgt:

[code]Systemfehler 64 aufgetreten.

Der angegebene Netzwerkname ist nicht mehr verfügbar.[/code]

Der Windows Server mit dem der Zugriff noch funktioniert, verhält sich ganz normal, befindet sich allerdings in einem anderen IP-Adressbereich.
Hier vermute ich die Ursache, finde aber keinen Hinweis mit dem ich dem Problem auf die Spur kommen könnte. Hierbei dachte ich an eine Einstellung hier finde ich jedoch keinen Hinweis.
Der Zufriff via SMB funktioniert an und für sich.
Z.B.
Der Zugriff auf \fileserver im Explorer funktioniert, die auf dem Fileserver bereitgestellten Shares werden angezeigt.
Nach einem Doppelklick auf einen Share vergehen mehrere Minuten danach erscheint der Logindialog. Ein Zugriff ist mit korrekten Benutzernamen und Kennwort dennoch nicht möglich. Die Fehlermeldung im Explorer lautet ebenfalls: “Der angegebene Netzwerkname ist nicht mehr verfügbar.”

Vom besagten Winows Server klappt der Zugriff mit genau diesen Logindaten ohne Probleme.

Über einen Tipp, ggf. in welchem Log und mit welcher Meldung ich der Ursache weiter auf die Schliche kommen könnte wäre ich dankbar.

Mit freundlichen Grüßen

Hendrik Dreyer

Hmm unschön. Können SIe bitte mal die Ausgabe von »ucr search --brief samba« hier anhängen?

Weiterhin sollten Sie mal das Debug-Level des Samba-Dämonen erhöhen. Sinnvollerweise wie folgt:

[ol][li]Auf einem noch nicht verbundenen Client im Explorer »\server« öffnen, aber noch keine Freigabe[/li]
[li]Auf dem Server mit »smbstatus« die Prozess-ID des Samba-Dämonen heraussuchen, der den in 1. genommenen Client bedient[/li]
[li]Für diese Prozess-ID das Loglevel mit »smbcontrol« hochsetzen (siehe Samba-Wiki, wie das genau geht)[/li]
[li]Logmeldungen in /var/log/samba für den Client untersuchen[/li][/ol]

Hallo,

vielen Dank für die Antwort.
Ich habe versucht das beschriebene Vorgehen umzusetzen, der Prozess wird aber innerhalb weniger Sekunden wieder beendet.
Sämtliche Log-Files unter /var/log/samba sind leer oder aber älter als 6 Monate.

Ich schaue einmal wo ich den Debug-level des Samba unter Univention hoch setzen kann und versuche mein Glück dann erneut.

Mit freundlichen Grüßen

Hendrik Dreyer

Das geht einfach mit

ucr set samba/debug/level=… service samba-ad-dc restart

Standardwert ist 1, wenn ich mich nicht irre.

Ich habe das jetzt so versucht:

smbcontrol smbd debug 10

Hat soweit auch geklappt aber das Log ist in kurzer Zeit etwas groß.
Ich habe es hier als 7z angehängt.

Hier nun die Ausgabe von ucr search --brief samba

appcenter/apps/samba-memberserver/status: installed
appcenter/apps/samba-memberserver/version: 4.3
directory/manager/samba3/legacy: <empty>
samba/acl/allow/execute/always: yes
samba/adminusers: administrator join-backup
samba/auth/methods: <empty>
samba/autostart: yes
samba/charset/display: <empty>
samba/charset/dos: <empty>
samba/charset/unix: <empty>
samba/client_use_spnego: yes
samba/cups/encrypt: <empty>
samba/deadtime: 15
samba/debug/level: 0
samba/domain/logons: auto
samba/domain/security: ads
samba/domainmaster: <empty>
samba/enable-msdfs: <empty>
samba/enable-privileges: <empty>
samba/encrypt_passwords: yes
samba/generate_smbpasswd: false
samba/getwd_cache: yes
samba/guest_account: nobody
samba/homedirletter: <empty>
samba/homedirpath: <empty>
samba/homedirserver: <empty>
samba/interfaces/bindonly: <empty>
samba/interfaces: <empty>
samba/invalid_users: <empty>
samba/kernel_oplocks: yes
samba/large_readwrite: yes
samba/ldap/replication/sleep: <empty>
samba/logonscript: <empty>
samba/machine_password_timeout: <empty>
samba/map_to_guest: Bad User
samba/max/protocol: <empty>
samba/max_log_size: <empty>
samba/max_open_files: 32808
samba/max_xmit: 65535
samba/memberserver/passdb/ldap: <empty>
samba/netbios/aliases: <empty>
samba/netlogon/sync: sync
samba/oplocks: yes
samba/os/level: 65
samba/passdb/expand/explicit: <empty>
samba/password/checkscript: /usr/share/univention-samba/password_check %u
samba/preserve_case: yes
samba/profilepath: <empty>
samba/profileserver: <empty>
samba/quota/command: /usr/sbin/univention-setquota
samba/read_raw: yes
samba/register/exclude/interfaces: docker0
samba/role: memberserver
samba/script/addgroup: true
samba/script/addmachine: true
samba/script/adduser: true
samba/script/addusertogroup: true
samba/script/deletegroup: true
samba/script/deleteuser: true
samba/script/deleteuserfromgroup: true
samba/script/postusermodify: false
samba/script/setprimarygroup: true
samba/serverstring: Fileserver 2
samba/share/groups: no
samba/share/home: yes
samba/share/netlogon/path: <empty>
samba/share/netlogon: no
samba/short_preserve_case: yes
samba/socket_options: <empty>
samba/spoolss/architecture: <empty>
samba/store_dos_attributes: yes
samba/time_server: yes
samba/use_spnego: yes
samba/user/pwdfile: /etc/machine.secret
samba/user: cn=fileserver2,cn=memberserver,cn=computers,dc=intern,dc=domain,de=tld
samba/usershare/allow_guests: <empty>
samba/usershare/max_shares: <empty>
samba/usershare/owner_only: <empty>
samba/usershare/path: <empty>
samba/usershare/prefix_allow_list: <empty>
samba/usershare/prefix_deny_list: <empty>
samba/usershare/template_share: <empty>
samba/vfs/acl_xattr/ignore_system_acls: <empty>
samba/wide_links: <empty>
samba/winbind/max/clients: <empty>
samba/winbind/nested/groups: no
samba/winbind/rpc/only: <empty>
samba/winbind/trusted/domains/only: <empty>
samba/write_raw: yes
samba4/ntacl/backend: native
security/packetfilter/package/univention-samba/tcp/137:139/all/en: netbios (Samba)
security/packetfilter/package/univention-samba/tcp/137:139/all: ACCEPT
security/packetfilter/package/univention-samba/tcp/445/all/en: microsoft-ds (Samba)
security/packetfilter/package/univention-samba/tcp/445/all: ACCEPT
security/packetfilter/package/univention-samba/udp/137/all: ACCEPT
security/packetfilter/package/univention-samba/udp/137:139/all/en: netbios (Samba)
security/packetfilter/package/univention-samba/udp/137:139/all: ACCEPT
security/packetfilter/package/univention-samba/udp/445/all/en: microsoft-ds (Samba)
security/packetfilter/package/univention-samba/udp/445/all: ACCEPT

Vielen Dank für die Unterstützung.

Mit freundlichen Grüßen

Hendrik Dreyer
smbd.7z (10.7 KB)

Hallo,

ich habe die Ausgabe von ucr search --brief samba mit einem Funktionierenden Fileserver in der Testumgebung verglichen.
Mal abgesehen von Domain und Servernamen sowie auch samba/serverstring ist alles exakt gleich.
Nach dem Update kommen allerdings die folgenden beiden Zeilen in der Ausgabe hinzu:

appcenter/apps/samba-memberserver/status: installed
appcenter/apps/samba-memberserver/version: 4.3

Ich könnte mir vorstellen, dass es mit dem DomainController zusammenhängt denn der Fileserver in der Testumgebung mit einem DomainController 4.0.3 versieht seinen Dienst klaglos.
Nehme ich genau diesen Fileserver, hänge ihn in das Produktivnetz und fahre ihn in die Produktive Domäne mit einem DomainController Version 4.1.0 kann ich auf keinen Share mehr zugreifen.

Genau so verhält es sich sobald der DomainController in der Testumgebung das Update auf 4.1.0 bekommen hat. Ab diesem Moment ist ein Zugriff auf die Shares des Fileservers nicht mehr möglich.

Setze ich den DomainController aus einem Snapshot zurück und führe für den Fileserver einen Join durch, funktionieren die Shares sofort wieder tadellos.

Die Testumgebung besteht aus einer Geclonten Produktivumgebung, ich werde mal eine Komplett neue Test-Domäne bauen und das Verhalten dann testen.

mit freundlichen Grüßen

Hendrik Dreyer

Wenn Sie so viel von »ins Testnetz hängen« und »wieder ins Produktivnetz« – dann sollten Sie noch mal versuchen, den File-Server im Produktivnetz erneut in die Domäne zu joinen und den Zugriff danach wieder zu testen.

Hallo,

das habe ich schon versucht. Ich habe die Fileserver auch chon restored um sie wieder in die Domäne zu heben. Das Resultat ist immer gleich.
Einzig der DomänenController behebt das Problem wenn ich ihn in der Testumgebung zurücksetze. Nur für diesen wieder ein Dowgrade in der produktivumgebung durchzuführen hat auch Folgen für diverste andere Server.
Das würde ich mir doch sehr gerne sparen.

Allerdings kann ich hier doch nicht der Einizige Nutzer mit solch einem Problem sein. Es muss hierfür doch einen Grund geben!

Die bisherigen Infos haben mir aber einen Ansatz gegeben an dem ich mich orientieren kann um das Problem weiter einzugrenzen.
Über eine weitere Hilfestellung würde ich mich dennoch sehr freuen. Insbesondere das smbd.log sagt mir nicht viel. Ich kann nicht beurteilen ob es normal aussieht oder ob es auffälligkeiten gibt.
Ein wenig vermisse ich einen Hinweis im Log auf Kerberos. Meldungen dieser Art vermisse ich hier, weiß aber auch nicht ob die überhaupt hier hinein geschrieben werden. Dahingehen habe ich mir die Logfiles für Kerberos noch nicht weiter angesehen. Werde ich nochmal tun.

Mit freundlichen Grüßen

Hendrik Dreyer

Ich habe versucht, das irgendwie hier nachzustellen, habe aber momentan keine 4.0er Server, die ich testweise misbrauchen könnte – daher nur direkt mit 4.1er Servern. Da gelang es mir nicht; der Zugriff auf die Shares (und die darin liegenden Dateien) auf dem separaten Fileserver funktioniert immer.

Können Sie bitte noch mal die Samba-Konfiguration einer dieser betroffenen Shares posten? Also den Inhalt von »/etc/samba/shares.conf.d/sharename« vom Fileserver.

Testen Sie bitte auch noch, eine komplett neue Share anzulegen (vorher den Fileserver erneut in Domäne joinen beim DC Master auf Stand 4.1) und danach den Zugriff auf diese neue Share.

Hallo,

ich habe zwei Shares und entsprechend Dateien vorgefunden.
Die Files sehen wie folgt aus:

263287 4.0K -rw-r–r-- 1 root nogroup 727 Dec 14 13:13 admin
263284 4.0K -rw-r–r-- 1 root nogroup 583 Dec 15 07:21 common

admin hat folgenden Inhalt

/etc/samba/shares.conf.d/admin: empty
/dev/stdin:                              ASCII text, with CR, LF line terminators
last:                           ERROR: cannot open `last' (No such file or directory)
mod_time::                      ERROR: cannot open `mod_time:' (No such file or directory)
Mon:                            ERROR: cannot open `Mon' (No such file or directory)
Nov:                            ERROR: cannot open `Nov' (No such file or directory)
30:                             ERROR: cannot open `30' (No such file or directory)
07:12:53:                       ERROR: cannot open `07:12:53' (No such file or directory)
2015:                           ERROR: cannot open `2015' (No such file or directory)

Dieser Inhalt erklärt sich mir nicht denn der Pfad funktioniert gelegentlich wieder.

common hat den folgenden Inhalt:

[common]
path = /volumes/vol2-commonfiles/commonfiles
vfs objects = acl_xattr
msdfs root = no
writeable = yes
browseable = yes
public = no
dos filemode = yes
hide unreadable = no
create mode = 0744
directory mode = 0755
force create mode = 00
force directory mode = 00
security mask = 0777
directory security mask = 0777
force security mode = 00
force directory security mode = 00
locking = 1
blocking locks = 1
strict locking = Auto
oplocks = 1
level2 oplocks = 1
fake oplocks = 0
csc policy = disable
nt acl support = 1
inherit acls = 1
inherit owner = no
inherit permissions = no

Der Ordner /volumes/vol2-commonfiles/ enthält die folgenden Unterordner:

drwxr-xr-x+ 5 Administrator Administrators 4096 Dec 14 20:01 admin
drwxr-xr-x+ 10 Administrator Administrators 4096 Dec 7 11:20 commonfiles

Diese sind entsprechend freigegeben.

Der Ordner /volumes/vol2-commonfiles ist der Mountpoint für einen separaten ext4 Datenträger. Dieser ist 541gb groß.

Mit freundlichen Grüßen

Hendrik Dreyer

Ich habe gerade den Share “admin” gelöscht. Zuvor habe ich den Pfad kopiert.
Danach habe ich den Share erneut erstellt und den kopierten Pfad wieder eingefügt.

Das File /etc/samba/shares.conf.d/admin sieht nun wie folgt aus:

[admin] path = /volumes/vol2-commonfiles/admin vfs objects = acl_xattr msdfs root = no writeable = yes browseable = yes public = no dos filemode = no hide unreadable = no create mode = 0744 directory mode = 0755 force create mode = 00 force directory mode = 00 security mask = 0777 directory security mask = 0777 force security mode = 00 force directory security mode = 00 locking = 1 blocking locks = 1 strict locking = Auto oplocks = 1 level2 oplocks = 1 fake oplocks = 0 csc policy = manual nt acl support = 1 inherit acls = 1 inherit owner = no inherit permissions = no

Der Zugriff funktioniert aber immer noch nicht. Der Fileserver hat die IP 10.0.0.40/24.
Wenn ich von einem Computer im Netz 10.0.0.0/24 versuche auf den Share zuzugreifen ergibt sich das bekannte Problem.

Wenn ich über VPN von der IP 10.1.0.2/24 verbunden bin, klappt der Zugriff auf alle Shares ohne Probleme. Egal ob es sich um Windows XP/2003/7/2008/8/2012 oder einer iPhone App handelt.
Verbinde ich einen dieser Computer mit dem lokalen Netz klappt auch der Zugriff auf die CIFS-Shares nicht mehr.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,

ich habe in den letzten Tagen mehrere Szenarien nachgestellt und auch im Rahmen einer vollständigen neuinstallation versucht das oben beschriebene Problem zu erkennen.
Leider komme ich bisher nur zu dem Schluss, dass Shares mit Univention Corporate Server 4.1 in keinem Szenarion funktionieren.

Egal wie ich es baue und egal auf welchem Hypervisor, in allen fällen kann auf CIFS-Shares nach dem Update auf 4.1 bzw. bei einer Neuinstallation direkt als Version 4.1 nicht zugegriffen werden.
Bei der Installation handelt es sich um einen frisch installierten SAMBA 4 DC und einen Mitgliedsserver mit einem Share.

Ich habe auch einen User erstellt um mit diesem den Zugriff zu testen aber es klappt nicht. Auch als Administator erhalte ich exakt das gleiche Fehlerbild wie in der Produktivumgebung.

Mit freundlichen Grüßen

Hendrik Dreyer

Noch einmal Hallo,

meine Aussage, dass Shares nicht funktionieren muss ich teilweise revidieren.
Shares funktionieren nicht im internen Netz. Sobald ich irgendwie einen Router dazwischen habe, also aus einem anderen Subnetz komme, kann ich auch auf die CIFS-Shares zugreifen!

Dies ist mein internes Netz: 10.0.0.0/24 .
Der Fileserver hat die IP 10.0.0.40, der DC die 10.0.0.41.
Mein Client ist im Bereich 10.0.0.100 - 200. Von hier kann ich nicht auf irgendwelche CIFS-Shares zugreifen.
Sobald ich mich via VPN einwähle habe ich die IP 10.1.0.2 und kann sofort auf alle Shares zugreifen.

Wenn ich mir intern eine Linux VM als Router aufsetze mit der IP 10.0.0.50 im internen Netz und der IP 192.168.1.1 im gerouteten Subnetz (beide in der gleichen Broadcastdomain auf eth0 (eth0:0 & eth0:1), meinem Client gebe ich dann z.B. die IP 192.168.1.100 kann ich ebenfalls auf die Shares zugreifen.

Wenn ich nun meinen Linux-Router herunterfahre und meinem Client die 10.0.0.50 gebe, habe ich wieder das alte Problem.
Ich kann auf keine Shares mehr zugreifen!

Mit freundlichen Grüßen

Hendrik Dreyer

Kannst du mal “ucr set samba/max/protocol=smb2; invoke-rc.d samba restart” auf dem DC Master ausführen und schauen ob das etwas ändert? Das ist die von Samba am höchsten zu verwendende SMB Version - falls ein Client damit nicht klar kommt würde er auf eine niedrigere Version zurückfallen, negative Auswirkungen sind also nicht zu befürchten.

Hallo,

vielen Dank für die Antwort. Ich habe auf dem Master DC die Variable gesetzt und dann versucht auf die Shares zuzugreifen.
[ul]\dc1\netlogon
\fs1\homeshare
\fs2\common[/ul]
Das Problem bleibt gleich.
Danach habe ich die Variable auch auf den Fileservern gesetzt und den Zugriff erneut getestet. Immer noch mit dem gleichen Problem.

Unter einer UCS Maschine habe ich versucht einen CIFS Share zu mounten. Hier bekomme ich den folgenden Fehler:

mount -t cifs //fs2.domain.tld/share /mnt/test -o user=username,password=password mount: wrong fs type, bad option, bad superblock on //fs02.intern.3er-online.de/common, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so

Versuche ich auf die gleiche Art und Weise einen Share von einem Windows-Client (also der Share wird vom Windows-Client beteitgestellt) zu mounten, funktioniert dies ohne Probleme.

Die Ausgabe von smbclient --list=dc1.domain.tld -U username zeigt die Shares des jeweiligen Systems an.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,

ich habe den Test soeben nocheinmal von externen Clients aus einem anderen IP-Adressbereich wiederholt:

[code]C:\Users\hdr>net use * \dc1.domain.tld\netlogon /user:NBDOMAIN\username
password
Laufwerk Z: ist jetzt mit \dc1.domain.tld\netlogon verbunden.

Der Befehl wurde erfolgreich ausgeführt.[/code]

Hier funktioniert es weiterhin. Intern ist ein Arbeiten aber weiterhin nicht möglich.

Mit freundlichen Grüßen

Hendrik Dreyer

Und noch einmal Hallo,

ich habe nun nocheinmal versucht CIFS-Shares zu mounten in dem ich anstelle des DNS- oder Hostnamens die IP angebe.
Das hat funktioniert!

Ich bin nun ein kleines Stück weiter. Ich kenne so ein ähnliches verhalten von Storagesystemen. Dort aber muss in der Regel der Name anstelle der IP übergeben werden.
Ich muss nochmal Recherchieren was ich dazu finde.

Remote funktioniert es mit DNS- oder Hostnamen als auch mit der IP.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,
Vielen Dank für den Hinweis. Ich meine hier [1] ein Muster zu erkennen und gebe das entsprechend zur Prüfung weiter.

Die Hinweise auf die IP-Subnetze könnten allerdings auch auf ein DNS-Problem hinweisen und damit ggf. auf Probleme bei Kerberos und/oder den “UNC Hardened Access” (das sind Änderungen, die über MS15-014 eingeführt wurden und UNC Pfade betreffen).

Funktioniert das Folgende?
a) Vom Fileserver oder DC aus per host
b) Vom Windows-Client aus z.B. per nslookup

Mit freundlichem Gruß,
Jens Thorp-Hansen

[1] - forum.univention.de/viewtopic.p … 06&p=17837

Hallo,

ich wünsche ein frohes neues Jahr.
Hostnamen zu IP und umgekehrt lassen sich intern als auch extern auflösen.
Ein Ping auf den Namen dc1 gibt auch Antwort vom dc1.domain.tld .
An und für sich klappt der Zugriff via DNS-Namen auf alle Server von intern und extern.

Der Zugriff auf \fs1.domain.tld oder \fs2.domain.tld klappt zunächst. Ich bekomme die auf dem Server bereitgestellten Shares an.
Sobald ich nun versuche einen Share zu öffnen kommt der Logindialog (unter Windows)
Ab dem Moment bekomme ich den besagten Fehler angezeigt, der Netzwerkname sei nicht mehr erreichbar.

Einzige Ausnahme ist der Domaincontroller. Auf diesen kann ich nur nach Eingabe des Benutzernamens und Kennworts zugreifen noch bevor irgendwelche Shares angezeigt werden.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,

ich habe heute zu Testzwecken eine Windows 7 VM in die Domäne gefahren. Mit dieser funktioniert der Zugriff auf Shares im internen Netz via FQDN auf alle betreffenden Systeme.
Nicht-DomainComputer können nicht auf Shares über den FQDN zugreifen wenn sie sich im internen Netz befinden.
Besagter Trick mit dem Router im Netz funktioniert aber für alle Computer, ebal ob Domainmitglied oder nicht.

Unter Linux gibt es immer das Problem mit dem CIFS-Share. Ich habe aber noch keine Kerberos-Anmeldung via Linux getestet.

mit freundlichen Grüßen

Hendrik Dreyer

Mastodon