11
Samba Freigabe - Zugriff scheitert
Hi Leute,
ich habe hier einen openSUSE Rechner auf dem ein SAMBA-Server läuft.
Auf diesem gibt es eine Freigabe "Daten", auf die die 5 eingerichteten User von Ihren Windows 10 Clients aus zugreifen können.
Heute wollte ich eine weiter Freigabe "Archiv" einrichten, die prinzipiell die selben Rechte haben soll, wie "Daten".
Ich habe den entsprechenden Abschnitt in der smb.conf kopiert und den Namen und den Pfad angepasst.
Das die beiden Verzeichnisse auf dem Linux-Rechner haben den gleichen Besitzer (root) und die gleiche Gruppe (users) und sowohl Besitzer als auch Gruppe haben volle Rechte.
Leider schaffe ich es nicht von einem der Windows-Clients aus die Freigabe "Archiv" zu öffnen.
Sie wird angezeigt, wenn ich \\server im Explorer eingebe, nach einem Doppelklick oder der Eingabe von \\server\archiv kommt aber eine Fehlermeldung, dass auf \\server\Archiv nicht zugegriffen werden könne.
Ich hättte keine Berechtigung dafür.
Das Selbe, wenn ich mich auf dem openSUSE Rechner per smbclient mit der Freigabe verbinde.
Die Verbindung wird hergestellt, aber ein "ls" z.B. mit NT_STATUS_ACCESS_DENIED listing \* quittiert.
Auch ein "md test" funktioniert nicht: "NT_STATUS_ACCESS_DENIED making remote directory \test.
Erstelle ich in der Konsole ein Verzeichnis, und versuche ein Verzeichnis mit dem selben Namen nochmals mittels smblient zu erstellen, bekome ich folgerichtig die Meldung
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \test
Irgendwo muss ich was übersehen - ich sehe nur nicht wo ;-/
An den Settings für die Freigaben kann es eigentlich nicht liegen
Ciao
dirk
ich habe hier einen openSUSE Rechner auf dem ein SAMBA-Server läuft.
Auf diesem gibt es eine Freigabe "Daten", auf die die 5 eingerichteten User von Ihren Windows 10 Clients aus zugreifen können.
Heute wollte ich eine weiter Freigabe "Archiv" einrichten, die prinzipiell die selben Rechte haben soll, wie "Daten".
Ich habe den entsprechenden Abschnitt in der smb.conf kopiert und den Namen und den Pfad angepasst.
Das die beiden Verzeichnisse auf dem Linux-Rechner haben den gleichen Besitzer (root) und die gleiche Gruppe (users) und sowohl Besitzer als auch Gruppe haben volle Rechte.
Leider schaffe ich es nicht von einem der Windows-Clients aus die Freigabe "Archiv" zu öffnen.
Sie wird angezeigt, wenn ich \\server im Explorer eingebe, nach einem Doppelklick oder der Eingabe von \\server\archiv kommt aber eine Fehlermeldung, dass auf \\server\Archiv nicht zugegriffen werden könne.
Ich hättte keine Berechtigung dafür.
Das Selbe, wenn ich mich auf dem openSUSE Rechner per smbclient mit der Freigabe verbinde.
Die Verbindung wird hergestellt, aber ein "ls" z.B. mit NT_STATUS_ACCESS_DENIED listing \* quittiert.
Auch ein "md test" funktioniert nicht: "NT_STATUS_ACCESS_DENIED making remote directory \test.
Erstelle ich in der Konsole ein Verzeichnis, und versuche ein Verzeichnis mit dem selben Namen nochmals mittels smblient zu erstellen, bekome ich folgerichtig die Meldung
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \test
Irgendwo muss ich was übersehen - ich sehe nur nicht wo ;-/
An den Settings für die Freigaben kann es eigentlich nicht liegen
[Daten]
comment = allgemeines Datenverzeichnis
inherit acls = Yes
path = /ClientData/Daten
read only = No
browseable = Yes
create mask = 0660
directory mask = 0770
force group = users
inherit permissions = Yes
[Archiv]
comment = Verzeichnis für alte Daten
inherit acls = Yes
path = /ClientData/Archiv
read only = No
browseable = Yes
create mask = 0660
directory mask = 0770
force group = users
inherit permissions = YesCiao
dirk
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 424853
Url: https://administrator.de/contentid/424853
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
11 Kommentare
Neuester Kommentar
Leider ist das Samba-Log auch nicht viel gesprächiger als die Konsole:
[2019/03/05 20:00:51.316277, 2] ../source3/smbd/dosmode.c:136(unix_mode)
unix_mode(test) inheriting from .
[2019/03/05 20:00:51.316381, 2] ../source3/smbd/dosmode.c:161(unix_mode)
unix_mode(test) inherit mode 40770
[2019/03/05 20:00:51.316698, 2] ../source3/smbd/open.c:4057(open_directory)
open_directory: unable to create test. Error was NT_STATUS_ACCESS_DENIED
Hallo,
Hat dein SUSE recht mit Access_Denied? Vielleicht existiert ein test ja schon.
Gruß,
Peter
Zitat von @diwaffm:
Auch ein "md test" funktioniert nicht: "NT_STATUS_ACCESS_DENIED making remote directory \test.
Und?Auch ein "md test" funktioniert nicht: "NT_STATUS_ACCESS_DENIED making remote directory \test.
Hat dein SUSE recht mit Access_Denied? Vielleicht existiert ein test ja schon.
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \test
Und? Gibt es schon ein test? Sicher das der Pfad richtig ist?An den Settings für die Freigaben kann es eigentlich nicht liegen
Ein SUSE besteht ja nicht nur aus ein Samba. Irgendwo überschneidet sich etwas oder dein Dateisystem ist hinüber, oder dein Samba und SUSE haben recht.Gruß,
Peter
Nein, zum Zeitpunkt des "NT_STATUS_ACCESS_DENIED" existierte \test noch nicht.
Erst danach habe ich das Verzeichnis in der Konsole angelegt.
Dann kam auch die passende Fehlermeldung...
Das "NT_STATUS_ACCESS_DENIED" kommt auch schon beim Versuch das Verzeichnis per ls oder dir auszulesen...
Erst danach habe ich das Verzeichnis in der Konsole angelegt.
Dann kam auch die passende Fehlermeldung...
Das "NT_STATUS_ACCESS_DENIED" kommt auch schon beim Versuch das Verzeichnis per ls oder dir auszulesen...
Hallo,
schön...
und nun gib noch zusätzlich bitte die Unix-Rechte auf diesen Verzeichnissen an !
7777 macht man nicht
, aber IIRR war da noch was mit GUID/SUID Bits, wenn andere ( User) werkeln.
Root ist sicher auch Gruppe root ? und die Users sind nicht Gruppe root ..zumindest sollte es so sein
Und ..steht dann doch im Log, wenn man Samba "geschwätzig genug" macht, ist aber dadurch auch schwerer zu finden
Fred
schön...
und nun gib noch zusätzlich bitte die Unix-Rechte auf diesen Verzeichnissen an !
7777 macht man nicht
, aber IIRR war da noch was mit GUID/SUID Bits, wenn andere ( User) werkeln.Root ist sicher auch Gruppe root ? und die Users sind nicht Gruppe root ..zumindest sollte es so sein
Und ..steht dann doch im Log, wenn man Samba "geschwätzig genug" macht, ist aber dadurch auch schwerer zu finden
Fred
Beide Verzeichnisse haben
drwxrwx--- also 770
Owner root und Group users - auch bei beiden...
Alle den Samba-Usern zugeordneten Linux-User sind Mitglied der Gruppe users - und können problemlos mit dem Daten-Verzeichnis arbeiten.
Die Linux-User haben auch Zugriff auf Archiv-Verzeichnis. Die zugeordneten Samba-User nicht.
drwxrwx--- also 770
Owner root und Group users - auch bei beiden...
Alle den Samba-Usern zugeordneten Linux-User sind Mitglied der Gruppe users - und können problemlos mit dem Daten-Verzeichnis arbeiten.
Die Linux-User haben auch Zugriff auf Archiv-Verzeichnis. Die zugeordneten Samba-User nicht.
Zitat von @diwaffm:
Alle den Samba-Usern zugeordneten Linux-User sind Mitglied der Gruppe users - und können problemlos mit dem Daten-Verzeichnis arbeiten.
Die Linux-User haben auch Zugriff auf Archiv-Verzeichnis. Die zugeordneten Samba-User nicht.
Alle den Samba-Usern zugeordneten Linux-User sind Mitglied der Gruppe users - und können problemlos mit dem Daten-Verzeichnis arbeiten.
Die Linux-User haben auch Zugriff auf Archiv-Verzeichnis. Die zugeordneten Samba-User nicht.
"zugeordnete" ?? Samba-User = das sind doch die gleichen wie die Unix-User ! Werden doch eh nur einmal las U*X-User angelegt mit ihren Gruppen dazu, was soll(te) da "zugerodnet" werden ?
max hat als U*x-User Rechte (RWX) in u*x-group smbx
/test/muuh hat die groupenn-ID smbx
und in der smc.conf wird das shar smbjuhu auf das Verzeichnis /test/smbx gemappt und der Win user max darf/kann arbeiten
Deine "Probleme" sind mir immer dann "über den Weg gelaufen" wenn smb-Rechte und U*X-Rechte nicht zueinander passten. (typisch für AzBis beim ersten Mal
- zumindest da ist es immer aufgefallen )Fred
Zitat von @fredmy:
"zugeordnete" ?? Samba-User = das sind doch die gleichen wie die Unix-User ! Werden doch eh nur einmal las U*X-User angelegt mit ihren Gruppen dazu, was soll(te) da "zugerodnet" werden ?
"zugeordnete" ?? Samba-User = das sind doch die gleichen wie die Unix-User ! Werden doch eh nur einmal las U*X-User angelegt mit ihren Gruppen dazu, was soll(te) da "zugerodnet" werden ?
Samba muss der User "bekannt" gemacht werden mittels sambapwd.
Nicht jeder Linux-User hat ein Samba-Passwort...
max hat als U*x-User Rechte (RWX) in u*x-group smbx
/test/muuh hat die groupenn-ID smbx
/test/muuh hat die groupenn-ID smbx
Ja, so ähnlich...
und in der smc.conf wird das shar smbjuhu auf das Verzeichnis /test/smbx gemappt und der Win user max darf/kann arbeiten
ja.
Deine "Probleme" sind mir immer dann "über den Weg gelaufen" wenn smb-Rechte und U*X-Rechte nicht zueinander passten. (typisch für AzBis beim ersten Mal - zumindest da ist es immer aufgefallen )
- zumindest da ist es immer aufgefallen )Ich habe 2 Verzeichnisse mit IDENTISCHEN Rechten, die in der smb.conf identisch gemappt werden - und die Windows-User haben nur Zugriff auf das eine...
Wenn die Windows-User auf KEINES der beiden Verzeichnisse Zugriff hätten, ok...
Aber wenn eines geht und eines nicht?
Das ist nicht der erste Samba-Server, den ich aufgesetzt habe - und DAS Problem hatte ich noch nie...
Ciao
dirk
Hallo Dirk,
die owner sind auch identisch ?
Und denk dran wenn du von A nach B kopierst ... deswegen sprach ich ja von den GUID(SUID) Bits die aber weiter oben in der Beispiel conf gar nicht vorkamen .
Fred
die owner sind auch identisch ?
Und denk dran wenn du von A nach B kopierst
... deswegen sprach ich ja von den GUID(SUID) Bits die aber weiter oben in der Beispiel conf gar nicht vorkamen .Fred
Ja, Owner sind identisch...
War root bei beiden - ist jetzt ein normaler Nutzer bei beiden.
Kein Unterschied im Verhalten...
GUID muss ich mir anschauen - war noch nie ein Thema...
Bin gerade über selbes Problem und bin über den Beitrag gestolpert - und dadurch auf die Lösung bei mir gefunden: Ich hatte einen Benutzer Xaaaaa angelegt, aber vermutlich lange Zeit zuvor einen xaaaaa (kleiner, statt großer Anfangsbuchstaben). Nachdem ich dann beide gelöscht und den ersten neu angelegt hatte, war alles so, wie erwartet.
Ohne, dass ich was geändert habe, ist das Problem nach einiger Zeit nicht mehr aufgetreten.
Das ist leider nicht die Art Problemlösung, die einem weiterhilft
Das ist leider nicht die Art Problemlösung, die einem weiterhilft
