Samba Freigabe übernimmt nicht die Rechte

  • Moin zusammen,

    woran kann es liegen wenn eine eingebundene Samba-Freigabe nicht die Rechte der Quelle übernimmt?

    Ich habe:

    • 1 Banana Pi M3 mit Ubuntu (16.04.6 LTS) als File-Server -> filesrv, Freigabe shares
    • 1 Rapberry Pi 3 B+ mit Raspbian (Buster) als Scan-Arbeitsplatz -> ScanPi
    • Mehrere Windows PCs (7 und 10)

    Ich habe auf dem File-Server Samba installiert und mehrere Freigaben eingerichtet. Auf allen Windows-PCs funktioniert die Freigabe auch ohne Probleme. Auf dem ScanPi habe ich die Freigabe wie folgt in der fstab eingebunden:

    //filesrv/shares /home/pi/smbshares cifs x-systemd.automount,x-systemd.requires=network-online.target,username=pi,password=******** 0 0


    Wenn ich mir nun den Ordner anschaue, in den die gescannten Dokumente gespeichert werden sollen, hat er verschiedene Rechte:

    • filesrv: drwxrwxr-x 2 pi users 4096 Nov 20 06:54 SCAN
    • scanpi: drwxr-xr-x 2 root root 0 Nov 20 06:54 SCAN

    Folglich kann ich vom Raspberry scanpi nicht in den Ordner schreiben.


    Die Freigabe "shares" ist wie folgt eingerichtet:

    [shares]

    path = /smbshares

    guest ok = no

    writeable = yes

    browseable = yes

    create mask = 0664

    directory mask = 0775

    hide unreadable = yes

    write list = user1, user2, root, pi


    pi ist als normaler user und als samba-user auf dem filesrv eingerichtet.


    Habt ihr Ideen? Danke!

    Chris

    • Official Post

    Die Rechte eines gemounteten Laufwerks sind max. so, wie die Rechte, die beim mounten vergeben werden. Auch die User und Gruppenzugehörigkeit sollte dabei beachtet werden. Siehe z.B. hier: https://wiki.ubuntuusers.de/mount/#Windows-Dateisysteme


    Ich hoffe ich habe das Problem richtig verstanden.

  • Danke, das hilft. Problem gelöst :)


    Aber nur dass ich das verstehe: Ich kann die Rechte vom Server einfach so "überschreiben", also neu setzen und so zum Besitzer der Dateien werden?

  • Aber nur dass ich das verstehe: Ich kann die Rechte vom Server einfach so "überschreiben", also neu setzen und so zum Besitzer der Dateien werden?

    Die Linux U-G-O Rechte hören - im Normalfall - an der Schnittstelle zum Fremdsystem (NTFS, CIFS/Samba, FAT) auf.

    Das fremde Filesystem wird unter dem Linux-User/Group angezeigt, der im Mountbefehl mit uid=/gid= festgelegt ist. Fehlt die Option uid/gid wird die uid/gid des aufrufenden Users herangezogen (das ist bei Dir uid=0, gid=0, also der User root.


    Umgekehrt werden die (nichtvorhandenen) Rechte eines Windows Users, wenn er auf ein Linux Filesystem über den Samba Server zugreift, von der Konfiguration des Samba Servers und der Linux User-/Gruppenverwaltung bestimmt. Da jeder Windows User einen korrespondierenden Linux User besitzt ([write list =] user1, user2, root, pi), kann der user1 sein /home/user1 Verzeichnis verwenden, wie er will (wegen des [homes]-Shares). Auf andere Verzeichnisse im Linux-Baum kann er lesend und lesend/schreibend nur mit den User-/Gruppenrechten zugreifen. Normalerweise sollte der user1 das home Verzeichnis des Users pi nicht einmal lesen dürfen, sodass er den CIFS Mountpoint im /home/pi Verzeichnis nicht erreichen kann.


    Den User root würde ich als Samba User SOFORT entfernen. Alles was Du remote am Linux richten willst, kannst Du per SSH auch.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Aber nur dass ich das verstehe: Ich kann die Rechte vom Server einfach so "überschreiben", also neu setzen und so zum Besitzer der Dateien werden?

    Richtig, Du kannst das nicht überschreiben. Wenn das auf einem Server über ein anderes Gerät (Client-PC) möglich wäre, wäre das mit Abstand die größtmögliche Katastrophe hinsichtlich der Datenintegrität und des Zugriffsschutzes. Eine solche Möglichkeit würde dem Server jegliche Glaubwürdigkeit absprechen.


    Stells Dir folgendermaßen vor:

    1. Das Server-Linux hat immer das letzte (und einzige) Wort über die Rechte auf Dateien in seinem Verantwortungsbereich und kann nicht von außerhalb 'überstimmt' werden.
    2. Samba (als Server-Prozess) kann diese Rechte niemals nach oben erweitern, allerdings kann es diese zusätzlich von oben und nach unten beschränken
    3. Es gibt keine Rechte-Synchronisation auf Dateien zwischen einem Client-PC und dem Samba-Server. Deshalb nicht, weil die Rechte auf einem Linux-System immer UID- und GID-orientiert sind und weil die auf unterschiedlichen Systemen vergebenen UIDs und GIDs niemals (d.h. ohne das man das ausdrücklich so vorsieht) inhaltlich oder nummerisch übereinstimmen.
    4. Auch wenn man in den Mount-Optionen UID und GID setzt, so hat das dennoch keinerlei Auswirkung auf die tatsächlichen Rechte des Server-Linux... denn wie gesagt, der Herr über die Rechte ist das Linux auf dem der Samba-Server läuft ...völlig egal, was da in den Mount-Options des Clients steht.... diese Angaben dienen nur der Anzeige von Fake-Rechten.
    5. Es werden auf einem Client-PC immer dessen Rechte für die Dateien des Samba-Shares angewandt, unter dessen UID der Share gemountet wurde. Das heisst, egal, wer auf dem Client-PC mit dem Share arbeitet, es passiert immer mit den Rechten dessen, der den Share gemountet hat.
    6. Von einem Client-PC auf dem Sambaserver gespeicherte Dateien werden überlichweise mit den Rechten des Sambauser dieses Servers gespeichert... zur Erinnerung, das ist eine andere UID als die, die auf dem Client-PC aktiv ist.
    7. Wenn man das mit den Sambarechten ordentlich handhaben will, richtet man einfach auf dem Samba-Server genau die Benutzer als Samba-User ein, die sich auch im heimischen Netzwerk als User anmelden.... und jeder einzelne User mountet die Shares mit seinen eigenen Rechten unter seiner eigenen UID... und zwar erst dann, wenn er sich am Bildschirm mit Name und Password anmeldet.
    8. Mit Punkt 7 spielt es keine Rolle mehr, auf welchem System ich arbeite, sobald ich die Shares mit meiner Samba-UID mounte, habe ich immer die passenden für mich geltenden Rechte.
    9. Linux ist nicht Windows.... ein wesentlicher Unterschied ist meiner Meinung nach, dass Linux nicht über die enormen Nachlässigkeiten eines Windows als Voreinstellung verfügt.