Fehler beim Zugriff auf Samba-Share

Hi Leute,

ich habe hier einen Samba Server (Version 4.12.0), der als NT4 PDC konfiguriert ist.
Darauf gibt es die nutzerspezifische Freigabe, auf die nur der angemeldete User Zugriff hat.
Diese wird am Client als F:\ gemappt.

Weiterhin gibt es eine allgemeine Freigabe, auf die alle Nutzer Zugriff haben.
Diese wird am Client als H:\ gemappt.

Letzte Woche wurde Corona-Bedingt nicht gearbeitet, und seit heut haben wir das
Nun haben wir seit heute das Problem, dass der Zugriff auf H:\ nicht dauerhaft funktioniert.
Starte ich Sambe (systemctl start smb), so kann ich von den Client aus auf H:\ Zugreifen.
Dateien lassen sich öffnen, Unterverzeichnisse auch.

Nach einer Weile (zwischen einer und zehn Minuten), ist dann kein Zugriff mehr möglich, es erscheint die Windows-Meldung

"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird".

Und zwar nicht nur beim Versuch, auf eine Datei im Verzeichnis zuzugreifen, sondern auch beim Klick im Explorer auf "H:\".

Weder im Log auf den Windows-Rechnern noch auf dem Server wird etwas angezeigt.
Es ist auch egal, ob der Client Teil der Domäne ist oder nur auf die Freigabe zugreift.

Laufwerk F:\ (das nutzerspezifische) ist immer erreichbar, auch wenn beim Klick auf H:\ der Fehler kommt...

Any ideas?

Danke
Dirk

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 564791

Url: https://administrator.de/contentid/564791

Ausgedruckt am: 22.11.2024 um 03:11 Uhr

11 Kommentare

Neuester Kommentar

Eine weitere Beobachtung:
So lange ich mich INNERHALB von H:\ in verschiedenen Unterverzeichnissen bewege, habe ich länger Zugriff,
klicke ich dann DIREKT auf H:\ kommt die Fehlermeldung... Aber auch danach habe ich noch Zugriff auf die Unterverzeichnisse...

So kann ich z.B. auf "H:\Texte" klicken und das Verzeichnis wird geöffnet.
Gebe ich "H:\Texte" in der Adresszeile des Explorers ein, kommt die Fehlermeldung...

Das Problem wird ausgelöst, durch den Lock des Verzeichnisses durch einen der angemeldeten Nutzer:

7824         1019       DENY_ALL   0x100080    RDONLY     NONE             /home/Daten   .   Wed Apr 15 08:23:20 2020
7824         1019       DENY_NONE  0x100081    RDONLY     NONE             /home/Daten   .   Wed Apr 15 08:12:19 2020

Stellt sich nur die Frage, warum der Lock eingerichtet - und warum er nicht wieder aufgehoben wird.

Hallo.

Bin jetzt nicht der Linux / Samba Experte, hatte aber schon mal damit experimentiert.

Was sagt denn Deine /etc/samba/smb.conf?

Sollte in etwa soetwas drinstehen:

[Samba]
path = /media/verzeichnis/share
public = yes
writable = yes

An den Berechtigungen oder den Freigabe-Einstellungen wurde hier nichts verändert, von der letzten Woche bis heute, korrekt?

Gruß
Radiogugu

Zitat von @radiogugu:
Was sagt denn Deine /etc/samba/smb.conf?

[daten]
        comment = Allgemeines Datenverzeichnis
        path = /home/Daten
        read only = No
        inherit permissions = Yes
        create mask = 0760
        directory mask = 0760
        force create mode = 0760
        force directory mode = 0760

Zitat von @radiogugu:
An den Berechtigungen oder den Freigabe-Einstellungen wurde hier nichts verändert, von der letzten Woche bis heute, korrekt?

Korrekt.
Die smb.conf hat sich seit 2 Jahren nicht geändert.

Dann hilft leider nur hoffen, dass sich ein Linux + Samba kundiger Forenteilnehmer meldet

Das sich ein Netzlaufwerk verbindet ohne Probleme und das andere nicht, scheint nicht logisch. Es sei denn die Konfigurationen unterscheiden sich irgendwo. Kann denn der Server selbst via smb auf das Verzeichnis zugreifen?

Gruß
Radiogugu

Ich habe das ganze jetzt mal weiter beobachtet.

Im "Normalbetrieb" kam es heute ca. 10x dazu, das eines oder mehrere der freigegebenen Laufwerke in Samba gesperrt waren.
Eigenartigerweise war es dabei in 7 von 10 Fällen EIN Nutzer, der die Sperren auslöste.
Das kann aber auch der Arbeitsweise geschultet sein.
Wenn er über den Datei-Öffnen-Dialog z.B. aus einer Webseite heraus eine Datei auf einem der Shares auswählen will und dazu zuerst auf "h:\" klickt, wurde der Lock gesetzt.

Da dieser Nutzer sowieso einen neuen PC kommen soll, habe ich diesen fertig gemacht und es damit probiert.

Sobald die Laufwerke im Logonskript zugewiesen werden ("net use h:\ //Server/Daten"), wird die Freigabe vom Samba gelockt - und nicht wieder freigegeben...

Bei einem anderen User, der einen identischen Rechner hat - und auch ein identisches Logonskript - taucht dieser Fehler nicht auf...

Trenne ich im Explorer die Verbindung mit dem Laufwerk, wird dann auch nach einiger Zeit der Lock aufgehoben...

Eigenartig...

Dirk

Was ist, wenn sich dieser User an einem anderen PC anmeldet und das Logon Skript durchläuft. Gibt es dasselbe Verhalten zu beobachten?

Eventuell ist ba an dem Logon Skript des Users oder eher noch dem lokalen Profil auf dem aktuellen PC etwas schief geraten.

Gruß
Radiogugu

Hallo Dirk,

ich kann dir leider keine Lösung für dein Problem anbieten, dafür jedoch etwas mehr Gewissheit, dass es nicht zwangsläufig an dir bzw. deiner Config liegt. Ich habe das Problem auch mit den aktuellen Samba-Versionen (4.12.0 / 4.12.1 / Aktuelle Nightly des Gitclones). In diversen Arch Linux Foren wird sich auch ausgiebig darüber beschwert, dass einige dieser Fehler wohl bereits seit 4.11.6 bestehen. Ich habe zudem testweise die Nightly Builds von TrueNAS (Nachfolger von FreeNAS) und LibreELEC probiert, in denen die aktuellen 4.12.x-Samba-Server ebenfalls enthalten sind und auch dort kann ich unsere Beobachtungen bestätigen.
In manchen Foren wird empfohlen, in der Config die Optionen

client min protocol = NT1

und

server min protocol = NT1

zu setzen, bei mir hat das allerdings nichts bewirkt.

Bleibt nur zu hoffen, dass Samba diese Fehler schnell fixt.

OK.
Das beruhigt mich ein wenig.
Dann war nicht mein (gleichzeitiges) Einrichten eines neuen Samba4 ADDC schuld (er eigentlich noch nichts mit dem Produktionssystem zu tun haben dürfte), sondern ein Systemupdate...

Eigenartigerweise tritt der Fehler bei manchen Clients häufiger auf als bei anderen.
D.h. die Locks gehören in 80% der Fälle zu 2 Useraccounts...

Gute Nachrichten - sie scheinen den Fehler gefixt zu haben. In der aktuellen Nightly Version kommen die Fehler bei mir nicht mehr. Getestet auf Ubuntu 20.04. Ein offizieller Patch dürfte daher wohl nicht lange auf sich warten lassen.