Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem beim Zugriff auf Share

3 views
Skip to first unread message

Dirk Wagner

unread,
Apr 14, 2020, 4:35:23 AM4/14/20
to
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

Dirk Wagner

unread,
Apr 14, 2020, 5:33:09 AM4/14/20
to
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...

ciao

dirk

Tim Ritberg

unread,
Apr 14, 2020, 2:01:44 PM4/14/20
to
Am 14.04.20 um 10:35 schrieb Dirk Wagner:
> Hi Leute,
>

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

>
> Any ideas?

Gibt es da Ordner oder Dateien die Root oder einem Admin gehören?
Mit sowas hatte ich mal Spaß, der Explorer kackt dann nämlich einfach so ab.

Tim

Ulf Volmer

unread,
Apr 14, 2020, 2:31:52 PM4/14/20
to
Dirk Wagner <usenet...@diwasoft.de> schrieb:

> 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:\".

Ich würde vorschlagen im Fehlerfall mit

smbstatus -L

zu schauen, was da gelockt wird.

Viele Grüße
Ulf

Marcel Mueller

unread,
Apr 14, 2020, 3:31:28 PM4/14/20
to
Am 14.04.20 um 10:35 schrieb Dirk Wagner:
> 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".

Nur mal so ins Blaue:

Windows-Büchse 1 (mit Schreibrechten auf H:\) legt eine versteckte Datei
desktop.ini (oder was auch immer) an und hält sie (warum auch immer)
offen. Windows-Büchse 2 will es ihr gleich tun und bekommt eine Sperre.

=> Entziehe doch im Wurzelverzeichnis von H mal *allen* die
Schreibrechte und erlaube den Zugriff nur tiefer. Also chown root:root,
chmod 755 auf das exportierte Verzeichnis.

Und gucke auch mal nach versteckten Dateien.


Marcel

ve...@rrzli.de

unread,
Apr 14, 2020, 4:43:08 PM4/14/20
to
Dirk Wagner <usenet...@diwasoft.de> wrote:
> 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.

Wie sieht die Freigabe in der smb.conf aus?

Dirk Wagner

unread,
Apr 14, 2020, 5:11:17 PM4/14/20
to
Andreas Kohlbach <a...@spamfence.net> wrote:

> Vielleicht den vollen Pfad angeben?
>
> \\IP_des_Servers\Texte

Macht keinen Unterschied...
Auch wenn ich einfach mit der "eine Ebene zürück"-Schaltfläche wieder
auf H:\ will, kann es zu der genannten Fehlermeldung kommen.



ciao

dirk

Dirk Wagner

unread,
Apr 14, 2020, 5:11:17 PM4/14/20
to
Ulf Volmer <u.vo...@u-v.de> wrote:

> Ich würde vorschlagen im Fehlerfall mit
>
> smbstatus -L
>
> zu schauen, was da gelockt wird.

Ja, das habe ich auch schon gemacht, komme da aber nicht wirklich
weiter...

Es müsste ja, wenn der Zugriff auf Dateien IM Verzeichnis (sogar im root
des Verzeichnisses) noch möglich ist, das Verzeichnis in SEINEM
Verzeichnis gelockt sein.

Und tatsächlich finde ich gerade jetzt dort den Eintrag
30782 1013 DENY_ALL 0x100080 RDONLY NONE
/home/Daten . Tue Apr 14 22:39:54 2020
30782 1013 DENY_NONE 0x100081 RDONLY NONE
/home/Daten . Tue Apr 14 22:39:54 2020

Und auf dem Rechner, auf dem der zur 30782 gehörende Nutzer angemeldet
ist, tritt der Fehler auf...

Nachdem ich dann von einem anderen Rechner aus auf ein Unterverzeichnis
von /home/Daten zugegriffen habe, sind nun auch die anderen Freigaben
gesperrt - diesmal von dem Nutzer, mit dem ich auf das Unterverzeichnis
zugegriffen haben:
28366 1019 DENY_ALL 0x100080 RDONLY NONE
/home/Disks . Tue Apr 14 22:54:07 2020
28366 1019 DENY_NONE 0x100080 RDONLY NONE
/home/Daten . Tue Apr 14 22:51:55 2020
28366 1019 DENY_ALL 0x100080 RDONLY NONE
/home/archiv . Tue Apr 14 22:54:07 2020
28366 1019 DENY_ALL 0x100080 RDONLY NONE
/home/Sport . Tue Apr 14 22:54:07 2020

Nach dem Löschen der Prozesse 28366 und 30782 kann ich wieder auf die
Freigaben zugreifen...

Stellt sich die Frage, was da passiert und wie ich es verhindern kann...

Ciao

Dirk

Dirk Wagner

unread,
Apr 14, 2020, 5:11:17 PM4/14/20
to
Tim Ritberg <t...@server.invalid> wrote:

> Gibt es da Ordner oder Dateien die Root oder einem Admin gehören?
> Mit sowas hatte ich mal Spaß, der Explorer kackt dann nämlich einfach so ab.

Alle Dateien / Verzeichnisse sind der Gruppe User zugeordnet und diese
hat volle Rechte auf das Verzeichnis...

ciao

dirk

Dirk Wagner

unread,
Apr 14, 2020, 5:11:17 PM4/14/20
to
Marcel Mueller <news.5...@spamgourmet.org> wrote:


> => Entziehe doch im Wurzelverzeichnis von H mal *allen* die
> Schreibrechte und erlaube den Zugriff nur tiefer. Also chown root:root,
> chmod 755 auf das exportierte Verzeichnis.

Ändert leider nichts am Verhalten.
Die in meiner Antwort auf Ulf gezeigten Sperren werden auch so noch
angelegt...

>
> Und guck auch mal nach versteckten Dateien.

Keine...
Weder auf der Linux- noch auf der Windows-Seite...

ciao

dirk

Dirk Wagner

unread,
Apr 14, 2020, 5:14:22 PM4/14/20
to
<ve...@rrzli.de> wrote:


> Wie sieht die Freigabe in der smb.conf aus?

[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

Das wurde das letzte Mal in 2016 geändert ;-)

Ciao

Dirk

Ulf Volmer

unread,
Apr 14, 2020, 6:14:10 PM4/14/20
to
Dirk Wagner <usenet...@diwasoft.de> schrieb:
> Ulf Volmer <u.vo...@u-v.de> wrote:
>
>> Ich würde vorschlagen im Fehlerfall mit
>>
>> smbstatus -L
>>
>> zu schauen, was da gelockt wird.
>
> Ja, das habe ich auch schon gemacht, komme da aber nicht wirklich
> weiter...
>
> Es müsste ja, wenn der Zugriff auf Dateien IM Verzeichnis (sogar im root
> des Verzeichnisses) noch möglich ist, das Verzeichnis in SEINEM
> Verzeichnis gelockt sein.
>
> Und tatsächlich finde ich gerade jetzt dort den Eintrag
> 30782 1013 DENY_ALL 0x100080 RDONLY NONE
> /home/Daten . Tue Apr 14 22:39:54 2020
> 30782 1013 DENY_NONE 0x100081 RDONLY NONE
> /home/Daten . Tue Apr 14 22:39:54 2020

Der erste Eintrag (mit DENY_ALL) ist tatsächlich schlecht, der zweite in
Ordnung. Ich kann das Verhalten aber mit meiner Spiel Windows 10 VM
nicht nachvollziehen, da taucht nur der zweite Eintrag auf.

Tritt das Verhalten mit einem frisch aufgesetzen Windows auch auf?

Viele Grüße
Ulf

Dirk Wagner

unread,
Apr 15, 2020, 1:45:10 AM4/15/20
to
Ulf Volmer <u.vo...@u-v.de> wrote:

> Der erste Eintrag (mit DENY_ALL) ist tatsächlich schlecht, der zweite in
> Ordnung. Ich kann das Verhalten aber mit meiner Spiel Windows 10 VM
> nicht nachvollziehen, da taucht nur der zweite Eintrag auf.
>
> Tritt das Verhalten mit einem frisch aufgesetzen Windows auch auf?

Ja
Es spielt dabei auch keine Rolle ob Win 7 oder 10.

Ciao

dirk

Dirk Wagner

unread,
Apr 15, 2020, 6:39:08 AM4/15/20
to
Ulf Volmer <u.vo...@u-v.de> wrote:

> Der erste Eintrag (mit DENY_ALL) ist tatsächlich schlecht, der zweite in
> Ordnung. Ich kann das Verhalten aber mit meiner Spiel Windows 10 VM
> nicht nachvollziehen, da taucht nur der zweite Eintrag auf.

Ich hatte gestern einen Beitrag bei Microsoft gelesen, der darauf
abzielte, dass SMB1 Verbindungen eine Sperre anfordern, diese dann aber
nicht mehr sauber freigegeben werden kann und SMB2 Verbinungen nicht
mehr auf das Share zugreifen können.

Ich habe aber keine Clients mit SMB1
Nur einige Windows 7 und 2 Windows 10 Clients mit SMB2 respektive SMB3.
Und diese Zusammensetzung der Clients hat sich in diesem Jahr auch nicht
geändert...

Ciao

dirk

Dirk Wagner

unread,
Apr 16, 2020, 12:12:26 PM4/16/20
to
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

Tim Ritberg

unread,
Apr 16, 2020, 12:48:14 PM4/16/20
to
Am 16.04.20 um 18:12 schrieb Dirk Wagner:
NT4DC, warum das?

Tim

Dirk Wagner

unread,
Apr 16, 2020, 1:23:54 PM4/16/20
to
Tim Ritberg <t...@server.invalid> wrote:

> NT4DC, warum das?

Weil das System bis jetzt problemlos lief und bei 10 Nutzern nicht
wirklich Bedarf für ein AD gesehen wurde.

Nun mit der Umstellung auf Win 10 ist das was anderes.


Das ist ja auch das Blöde an der Situation: Am Testserver mit 2
Testclients läuft schon der ADDC im Samba 4.
Aber bislang nur der DC und kein Fileserver - und nein, es gibt keine
Überschneidungen der Netze / Nutzer...

NOCH ist alles getrennt.
Vielleicht ist die Suche nach dem Fehler im alten System unnötig.
Aber dank Corona, komme ich nicht dazu, das Rechnerupdate und die
Servermigration zeitnah durchzuführen.

Das muss quasi parallel passieren.

ciao
dirk

Tim Ritberg

unread,
Apr 16, 2020, 2:03:45 PM4/16/20
to
Am 16.04.20 um 19:23 schrieb Dirk Wagner:
> Tim Ritberg <t...@server.invalid> wrote:
>
>> NT4DC, warum das?
>
> Weil das System bis jetzt problemlos lief und bei 10 Nutzern nicht
> wirklich Bedarf für ein AD gesehen wurde.
>
> Nun mit der Umstellung auf Win 10 ist das was anderes.
Hab selbe Umgebung und einen DC mit univention server. Läuft super.

Tim
0 new messages