Habe eine Partition erstellt die ich als Datenablage für alle nutzen möchte. Partition ist ext4, kann ich aber noch ändern, einzige Voraussetzung ist, es muss ein Linux Dateisystem sein. Bisher bekomme ich sie nur Lesend eingehangen.
Was muss denn jetzt alles in die fstab, damit das funktioniert?

  • brikler hat auf diesen Beitrag geantwortet.

    Wenn es um (Schreib)-Rechte in der "Wurzel" der Datenpartition, also im Einhängepunkt geht:

    Angenommen (als root):
    mkdir /daten
    mount /dev/part_data /daten

    /daten hat als Owner/Group nun root:root. Daran ändert auch nichts, dem Einhängepunkt vorher per chmod/chown andere Rechte zu geben.

    Allerdings:
    chown andy:andy /daten
    (während die Partition eingehängt ist, chmod ggf. anpassen)
    bewirkt daß:
    a) adhoc andy nach /data (in die "Wurzel") schreiben kann und
    b) Nach dem umounten und erneut mounten sind diese Rechte auch wieder da

    Hintergrund: Nach dem Formatieren eines Linux-Dateisystems hat dieses FS - obwohl nominell "leer" - ja auch Rechte, also für namentlich ausgedrückt: /dev/sdxy/ (Slash) oder im Einhängepunkt /daten/. (Punkt)
    Diese sind anfangs root:root und (die Crux!) werden im Dateisystem der Partition gespeichert.

    Deshalb wird das (übergeordnete) Mount-Dir - auch wenn nodody:nobody und 0777 - immer von den Rechten der "imaginären" Wurzel des einzuhängenden Dateisystems ersetzt.
    Setzt man diese aber einmalig wie gewollt dann bleiben diese im Dateisystem erhalten.

    Es braucht also (anders als bei Nicht-Linux-Dateisystemen) keine "Vorgaukelung" von Rechten, der Eintrag in die fstab kann also ohne besondere Optionen geschehen.

    Nach dem korrekten Einrichten der Eigentümer/Zugriffs-Flags für die Partition eingehängt nach /daten gilt ab da dann die "normale" Eigentümer/Zugriff-Flags wie in jedem ext4-Dateisystem, abhängig der umask oder anderer Regelungen z.B. per ACLs.
    Wenn Dateien/Verzeichnisse in weiteren unteren Ebenen nun nicht nur für andere lesbar, sondern auch für andere als den jeweiligen Eigentümer schreibbar sein sollen brauchst du eine andere Dateisystem-Strategie für die Rechte-Verwaltung.

    • Andy@Arch hat auf diesen Beitrag geantwortet.
      $ whatis acl
      acl (5)              - Access Control Lists

      man acl
      https://wiki.archlinux.org/title/ACL

      ACLs sind extrem hilfreich für Eigentümer/Zugriffs Rechteverwaltung wenn man bei der normalen user:group:other und den Zugriffsflags an Grenzen stößt bzw. sehr feingradige Zugriffsmechanismen benötigt. 85% der Fälle lassen sich aber IMHO per normaler Rechteverwaltung lösen.

      Tip:
      "whatis" ist wie "apropos" ein sehr hilfreiches Kommando.

      Verschüttetes Urzeitwissen. Ich musste mich auf pacman-dev mal auslachen lassen, weil ich den Befehl "stat" nicht kannte (ist so ähnlich wie "touch"). Nur GerBra weiss so etwas noch. Was machen wir nur, wenn der nicht mehr ist?

      • GerBra hat auf diesen Beitrag geantwortet.

        matthias Verschüttetes Urzeitwissen

        ROFL ;-)

        matthias Was machen wir nur, wenn der nicht mehr ist?

        Einen alten Kofler oder ein Addision-Wesley Linux Handbuch "schießen" und für die - immerhin mögliche - Hej-kein-Internet! Szenarien bereithalten ;-)

        'stat' ist aber neumodisches Linux-Zeug. Unter alten Unixen gabs das nicht.

        • schard hat auf diesen Beitrag geantwortet.

          @GerBra Danke für die Aufklärung

          Ich hab da mal was gebastelt ist aber noch Rohbau
          `[Unit]
          Description= Systemd Service
          After=

          [Service]
          Type=simple
          ExecStart=mount -L "Label" /mnt/"Mountpunkt"/
          ExecStart=find /mnt/"Mountpunkt" ! -perm 777 -print -exec chmod 777 {} \;
          ExecStop=umount -L "Label"

          [Install]
          WantedBy=multi-user.target`
          Bei After= steht noch nichts weil ich da gerade nicht weiterkomme. Ich möchte das der Service ausgeführt wird sobald sich ein irgendein user lokal einloggt, also nicht über ssh.

            Andy@Arch Ich hab da mal was gebastelt

            Wozu?

            Ausserdem (für Bastler):

            • Fürs Einhängen via systemd gibt es eigene SystemD Mount Units
            • Das Setzen/Überprüfen von Dateiberechtigungen wird besser mit systemd-tmpfiles erledigt (man 5 tmpfiles.d)

            Andy@Arch -exec chmod 777

            Ich kenne ja deine Anforderungen bzgl. "alle User" nicht, also die Absicht hinter der "Datenpartition lesend/schreibend für alle", aber...
            777 ist meist die "dümmste" Lösung und heißt letztendlich nur: ich bin zu faul mich mit der Rechteverwaltung zu beschäftigen.
            Zumindest solltest du die Partition dann mit noexec einhängen.

            • Andy@Arch hat auf diesen Beitrag geantwortet.

              schard analog zu /tmp konfigurieren. D.h. 1777 (mit Sticky Bit).

              Wie mache ich das? mode=1777 funktioniert nicht mit ext4, fmask= , dmask= oder umask= funktioniert auch nicht.

              @GerBra das 777 war jetzt nur mal aus der Luft gegriffen, vermutlich würde Besitzer und Gruppe Lesen, Schreiben und ausführen würde vermutlich auch genügen.

              Was macht denn das Sticky Bit genau?

              0 ✓ srv ~ $ man chmod | grep sticky
              user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). Instead of one
              (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who
              The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type.
              program’s text image on the swap device so it will load more quickly when run; this is called the sticky bit.
              0 ✓ srv ~ $

              https://de.wikipedia.org/wiki/Sticky_Bit

              GerBra Ich kenne ja deine Anforderungen bzgl. "alle User" nicht, also die Absicht hinter der "Datenpartition lesend/schreibend für alle"

              Anforderung = Krabbelkiste. Jeder User an dem Rechner soll in der Lager seine dort etwas zu Speichern, Verändern oder Löschen und jeder der dort etwas ablegt weiß das auch. Bisher hab ich für so was immer ntfs genommen, möchte ich aber nicht mehr wegen Windows.

              Partition habe ich jetzt mit owner:root | group:users eingehangen und alle User der Gruppe users hinzugefügt. Keine Ahnung ob das so richtig ist, es funktioniert erstmal.

              Des weiteren habe ich noch ein klitzekleine Script zum anpassen der Rechte geschrieben was ich bei Bedarf per SSH ausführen kann.
              Das würde ich aber lieber als Systemd-Service machen, weiß aber leider nicht was ich in den File reinschreiben muss, damit der Service beim Userlogin ausgeführt wird. Falls da jemand noch eine Idee hat.

              • brikler hat auf diesen Beitrag geantwortet.

                Andy@Arch damit der Service beim Userlogin ausgeführt wird

                wie meinst du das? wenn du als $USER eine session startest, oder einfach wenn du bootest?
                als $USER was mounten, durfte eigentlich nicht funktionieren, den mount ist root vorbehalten.

                Wieso so kompliziert? Wenn du den Ordner oder das Laufwerk NAS nennst, dann kannst du das Bsp. so abschreiben wie es ist.
                https://wiki.archlinux.de/title/Network_File_System
                Du kann dann auch auf NAS Ordner anlegen mit der user ID, die jeweils die Benutzer haben die darauf zugreifen dürfen.
                Und du kannst für einen Ordner in dem alle lesen, bzw schreiben dürfen die Gruppenrechte entsprechend setzen. Du musst halt nur die UID auf den Rechnern die darauf zugreifen die UIDs entsprechend verteilen.
                Z.B. Andy 1000, Monika 1001, Grieselda 1002 ......
                Diese Zuordnung muss auf allen Geräten die auf NAS zugreifen dürfen, die selbe sein, dann kommt sich niemand in die Queere.

                Zur UID siehe hier: https://wiki.archlinux.de/title/Benutzer_und_Gruppen

                (Falls du dann überhaupt noch ein script brauchst, dann gäbe es auch noch den Befehl 'remount'.
                Den nutze ich nach erfolgter Sicherung um die Lese/Schreibrechte von rw auf r zu stellen. Systemd benötigst du eigentlich nur dann, wenn du etwas automatisieren möchtest. Das script bliebe aber das gleiche. Und natürlich wird mount oder remount immer unter root Rechten ausgeführt und mit systemd nutzt eigentlich auch immer rootrechte, es sei denn du deklarierst den jeweiligen Dienst exlizit mit der --user.Option aber das brauchst du in diesem Falle gar nicht.)

                @brikler das mounten ist auch nicht mehr das Problem, das Problem ist das Andy 1000, Monika 1001, Grieselda 1002 ...... hat.
                Ich möchte, das beim Anmelden vom User, ein Befehl ( find /mnt/"Mountpunkt" ! -perm 770 -print -exec chmod 770 {} \; ) mit Rootrechten ausgeführt wird. Deswegen darf der Systemd Service auch kein systemctl --user *.service sein.

                Was mir jetzt noch fehlt ist ein Target (also Before=, After= usw) im Service der den Zeitpunkt wenn ein Benutzer grafisch eine Session startet definiert. Ein "After=sddm" hat hier nicht funktioniert.
                Nach dem Boot funktioniert leider auch nicht, weil der Rechner beim Benutzer wechsel nicht immer neu gestartet wird.

                • Dirk und tuxnix haben auf diesen Beitrag geantwortet.

                  Andy@Arch Ich möchte, das beim Anmelden vom User, ein Befehl ( find /mnt/"Mountpunkt"

                  Ich weiß gar nicht weshalb du da rum mounten willst.
                  Wenn du auf einem Rechner arbeitest, dann lässt du es bei /home/griselda ect.
                  Dann ist da alles perfekt eingerichtet.
                  Wenn du von mehren Rechnern zugreifen willst, dann kannst du auch per nfs /home frei geben und der jeweilige Zugriff wird beim einloggen mit der UID geregelt.
                  Du kannst auch einen Ordner /NAS taufen und dort dann ein /NAS/griselda anlegen.
                  Mounten muss dann jeweils nur der Clientrechner und zwar den nfs Ordner auf dem Serverrechner.

                  Eine extra Festplatte oder Partition, brauchst du eigentlich nur dann, wenn dir der Speicherplatz zu eng wird.
                  Ich schlage vor du machst es dir einfach und und tust ein '# mkdir /NAS. Dort Legst du die Ordner Andy, Monika Grieselda an und gibst ihnen dann auch die UID von Andy, Monika und Griselda wie sie auf allen anderen Rechnern vergeben sind. (Fürs System zählen halt nicht die Namen sondern nur die UID)
                  Wenn dann alles funst und erst dann und wie gesagt mounten tut hier nur der Clinet Rechner, dann kannst du du auch eine Festplatte den Namen NAS geben und die Ordner mit # cp -ra dort rüberkopieren. Das -a steht für Archiv und behält die Rechte so wie sie im Original sind. Danach mountest du die Platte NAS auf den Mountpoint (Ordner) /NAS. und schreibst das mounten dieser Festplatte in die fstab. 1x fertig!.

                  Ein find Mountpoit braut es nicht. Der Server hat in der exports genau definiert welcher Rechner auf welchen Ordner zugreifen darf. Und der Client Mountet dann diesen Ordner der sich auf dem Server befindet.
                  Das schreibt man auch in die fstab des Clint, wenn das immer so sein soll. Das macht man am besten aber mit der Angabe nofail damit der Client auch dann noch startet, wenn der server mal down sein sollte.