Richtiges mounten von externen SSDs mit Zugriffsrechte für Docker Container

    Grüß euch,
    Könnt ihr mir sagen wie ich eine externe SSD am Pi mounten kann, so dass ich Schreib- und Ausführungsrechte habe?

    Jedes Mal wenn ich meine SSD mounte
    sudo mount /dev/sda2 /media/externSSD/

    steht dass der Besitzer und die Gruppe root sind.

    Wenn ich dies mit chown und chmod auf den User "admin" ändere, kann ein Docker Container trotzdem nicht auf die externe SSD schreiben oder Ordner und Files erstellen. PUID und PGID sind auf "1000" gesetzt was gleichzusetzen mit dem User "admin" ist.

    Auch das Ändern der Besitzrechte der SSD hat mir nicht geholfen.

    Code
    >>  ls -l /dev/sda2
brw-rw---- 1 root disk 8, 2 Jul 16 19:48 /dev/sda2

>>  sudo chown -R admin:admin /dev/sda2
>> ls -l /dev/sda2
brw-rw---- 1 admin admin 8, 2 Jul 16 19:48 /dev/sda2

>>  sudo chmod u=rwx,g=rwx,o= /dev/sda2
>> ls -l /dev/sda2
brwxrwx--- 1 admin admin 8, 2 Jul 16 19:48 /dev/sda2


    Da ich ein LinuxAnfänger bin komme ich trotz googeln nicht mehr weiter.
    Hättet Ihr hilfreiche Ratschläge für mich?


    Beste Grüße
    Fox-Jet

  • Richtiges mounten von externen SSDs mit Zugriffsrechte für Docker Container? Schau mal ob du hier fündig wirst!

    ls -l /media/externSSD wäre interessanter.

    Davon abgesehen hängt es vom Dateisystem des Datenträgers, bzw. der Partition /dev/sda2 ab, ob Benutzer und Gruppe beim Mounten gesetzt werden müssen oder nicht.

    Siehe dazu u.a. hier: https://wiki.ubuntuusers.de/mount/#Dateisystemrelevante-Rechte

    Die Schreibrechte in einem gemounteten Filesystem werden von den Mount-Optionen, und nicht vom Mountpoint bestimmt.

    Auch der Typ des Filesystems (ext4, ntfs, exfat, nfs, cifs, btrfs, xfs, ...) sollte ausdrücklich angeführt sein, weil sonst die "automount Funktion" falsche Standardoptionen zuweist, wenn diese nicht in der Optionen Kette angeführt sind.

    Sonst ist im Link von #2 alles beschrieben, inbesondere auch der Unterschied der Windows Filesysteme zum Rest der Welt.


    Servus !

    RTFM = Read The Factory Manual, oder so

    • New
    Quote from hyle

    Siehe dazu u.a. hier: https://wiki.ubuntuusers.de/mount/#Dateisystemrelevante-Rechte

    Das mit dem Einbinden mit den Zusatzoptionen hat super funktioniert!

    Jetzt hätte ich nur noch ein paar Fragen:
    1.) da mein System mit einem reboot letztens ziemlichen Schaden genommen hat möchte ich nur ungern mein SSD dauerhaft dynamisch mit sudo mount -t vfat -o uid=1000,gid=1000 /dev/sda2 /SSDmusic mounten.

    Im Wiki für fstab steht unter "Einbinden beenden", dass :

    Quote

    Alle eingehängten Geräte und Dateisysteme werden beim Herunterfahren des Systems automatisch korrekt wieder ausgehängt.

    Wird somit verhindert, dass bei einem Shutdown oder Reboot die Files auf der SSD wieder korrupt werden können?

    2.) wenn ich die fstab Datei bearbeite sind die "Spalten" durch Tabstopps von einander getrennt, oder sind hier einfach Leerzeichen für eine optische Gliederung und das System liest einfach nach der Reihe "file_system, mount_point, type usw." ein?

    Code
    # file_system                              mount_point     type         options                   dump pass
UUID=03b77228-ed4c-4218-910e-11b9f77c4b46  /               ext4         errors=remount-ro            0 1
UUID=8883dbc8-80f8-49b8-8c5f-13a32baefe98  none            swap         nofail
UUID=65D1-EDBF                             /boot/efi       vfat         noauto,user,umask=022        0 2
/dev/sda2                                  /media/sda1     ntfs3        nofail,nodev,noexec,windows_names

/dev/sdb	                               /media/Daten    vfat         noauto,user,umask=222
LABEL=Backup-3                             /media/Backup   ext4         noauto,user
/dev/cdrom                                 /media/cdrom0   udf,iso9660  noauto,ro,user

    3.) Ist die UUID einer externen SSD fix zugeordnet oder ist die UUID dem Hardware Slot (z.b obere USB3 Buchse am Pi) zugewiesen? Ich frage deswegen, da ich nicht sicher bin ob es besser ist die SSD per "/dev/sda2" oder per UUID einzubinden?

    4.) Was macht genau die "noauto" Option. Beim Verwenden dieser Option wird die SSD beim Starten nicht eingebunden, hab ich das richtig verstanden? Sollte ich bei den Optionen "noauto" nutzen oder sind die Optionen "uid=1000,gid=1000" ausreichen?

    5.) Sollte ich pass = 2 setzen für meine externe SSD? Oder ist ein prüfen nicht notwendig? Ich würde auf der externen SSD nur Audiofiles speichern um diese über meinem DAC (HifiBerry) abzuspielen.

    • New
    Quote from Fox-Jet

    Wird somit verhindert, dass bei einem Shutdown oder Reboot die Files auf der SSD wieder korrupt werden können?

    Die Aussage ist, dass vor dem Trennen der Datenträger ein umount stattfindet, bei dem automatisch vor dem Aushängen ein sync gemacht wird.

    Quote from Fox-Jet

    Ist die UUID einer externen SSD fix zugeordnet

    Ja.

    Quote from Fox-Jet

    Was macht genau die "noauto" Option. Beim Verwenden dieser Option wird die SSD beim Starten nicht eingebunden, hab ich das richtig verstanden?

    Ja, hast Du! Wichtig ist trotzdem (zur Sicherheit) auch die Option nofail, die verwendest Du ja schon bei dem NTFS-Laufwerk. //Edit Ach nee, das ist ja ein Beispiel der Ubuntuusers von hier: https://wiki.ubuntuusers.de/fstab/#Grundlagen

    Quote from Fox-Jet

    Sollte ich bei den Optionen "noauto" nutzen oder sind die Optionen "uid=1000,gid=1000" ausreichen?

    Verwendest Du noauto musst Du nach dem booten das Laufwerk mit mount -a manuell mounten, aber das hattest Du ja schon richtig vermutet.

    Quote from Fox-Jet

    Sollte ich pass = 2 setzen für meine externe SSD? Oder ist ein prüfen nicht notwendig?

    Wenn die wirklich vfat ist, dann kannst Du das auf 0 setzen, denn da wird eh nichts überprüft.

    • New
    Quote from hyle

    Wichtig ist trotzdem (zur Sicherheit) auch die Option nofail, die verwendest Du ja schon bei dem NTFS-Laufwerk.

    Das ist die Beispielsdatei von ubuntuuser.de.

    Meine fstab sieht wie folgt aus:

    Code
    proc            /proc           proc    defaults          0       0
PARTUUID=bd153b09-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=bd153b09-02  /               ext4    defaults,noatime  0       1

    Was sind eigentliche diese "proc" Felder?


    Hätte jemand eine Antwort zu dieser Frage?

    Quote from Fox-Jet

    2.) wenn ich die fstab Datei bearbeite sind die "Spalten" durch Tabstopps von einander getrennt, oder sind hier einfach Leerzeichen für eine optische Gliederung und das System liest einfach nach der Reihe "file_system, mount_point, type usw." ein?

    • New
    Quote from Fox-Jet

    Hätte jemand eine Antwort zu dieser Frage?

    Quote from Fox-Jet

    2.) wenn ich die fstab Datei bearbeite sind die "Spalten" durch Tabstopps von einander getrennt, oder sind hier einfach Leerzeichen für eine optische Gliederung und das System liest einfach nach der Reihe "file_system, mount_point, type usw." ein?

    1 Leerzeichen reicht, Tabstops machen es meist lesbarer.

    Das heißt aber auch, dass Leerzeichen innerhalb einer "Spalte", z.B. bei Freigabenamen, immer escaped (\040) werden müssen.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    • New
    Quote from Fox-Jet

    Hätte jemand eine Antwort zu dieser Frage?

    Von mir kommt ein nein.

    Deine Frage wird von der man-page auf Deinem System beantwortet. "man fstab"


    Code
     DESCRIPTION
 .....
 
       Each filesystem is described on a separate line. Fields on each line
       are separated by tabs or spaces. Lines starting with '#' are comments.
       Blank lines are ignored.
.....

    Jedes in /usr/bin und /usr/sbin enthaltene Programm hat eine man-page, in welcher das Programm und alle Optionen und Argumente aktuell beschrieben sind.

    Das Programm "man" hat selber auch eine man-page, sie wird mit "man man" angezeigt.


    Servus !

    RTFM = Read The Factory Manual, oder so

    • New

    Dachte Manual pages gibt es nur von Befehlen. Danke für denk Hinweis :)

    ---

    Ich habe jetzt die USB SSD versucht per fstab statisch zu mounten, jedoch wurde die SSD nach einem reboot nicht gemountet.

    SSD UUID:

    fstab:

    Code
    # file_system         mount_point     type         options                   dump pass
proc            /proc           proc    defaults          0       0
PARTUUID=bd153b09-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=bd153b09-02  /               ext4    defaults,noatime  0       1
PARTUUID=403F-1A00    /SSDmusic       vfat    nofail,uid=1000,guid=1000  0   0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

    Nach dem Reboot:

    Code
    admin@raspberrypi:~ $ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0   200M  0 part 
└─sda2   8:2    0 931.3G  0 part 
sdb      8:16   0 465.8G  0 disk 
├─sdb1   8:17   0   512M  0 part /boot/firmware
└─sdb2   8:18   0 465.3G  0 part /

    Edited once, last by Fox-Jet: Ergänzung (February 16, 2025 at 11:31 AM).

    • New

    Wnn du per PARTUUID mountest, dann musst du auch die PARTUUID eingeben und nicht die UUID


    Wenn du die PARTUUID anzeigen lassen willst, dann benutze

    blkid

    oder

    lsblk -o NAME,MOUNTPOINT,UUID,PARTUUID

    • New
    Quote from Franjo G

    Wnn du per PARTUUID mountest, dann musst du auch die PARTUUID eingeben und nicht die UUID

    Die UUID ist doch genauso einzigartig wie die PartUUID, sollten hier nicht beide Optionen funktionieren?

    Quote from RTFM

    Eine knapp 1 TB grosse Partition mit FAT32 zu formatieren halte ich für ziemlich problematisch.

    Frag mich nicht warum, das musst Du Dir selbst erarbeiten.

    Die Idee war, dass ich meine Music auch mit meinem Mac und meinem Windows PC auf die SSD kopieren kann. Ich hatte damals ziemliche Probleme mit exFAT und dem Raspi. (höchstwahrscheinlich Anwenderfehler) Hast du dafür eine bessere Idee?

    Noch ist die Platte leer (bis auf 1 Album zum Testen)

    • New

    Die Schnittmenge bei Dateisystemen zwischen macOS und Windows ist leider sehr klein. Da ist Fat32 wahrscheinlich das geringste Übel, wenn man mit der max Filesize < 4 GiB leben kann.

    Auch wenn Fat32 ziemlich alt ist und Windows sich mit Bordmitteln etwas sperrt, Dateisysteme >32 GiB damit zu formatieren, so kannst du es getrost bis 2 TiB einsetzen.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    • New
    Quote from Franjo G

    Wnn du per PARTUUID mountest, dann musst du auch die PARTUUID eingeben und nicht die UUID

    Habe jetzt erst verstanden was du gemeint hast. Bei mir mounten er es auch mit der PartUUID nicht nach einem reboot. Muss das Laufwerk vor dem Reboot bereits "dynamisch" einmal auf dem Mountpoint gemounted worden sein?


    Code
    # file_system         mount_point     type         options                   dump pass
proc            /proc           proc    defaults          0       0
PARTUUID=bd153b09-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=bd153b09-02  /               ext4    defaults,noatime  0       1
PARTUUID=fb736042-c743-417f-b133-e7380846f80e    /SSDmusic       vfat    nofail,uid=1000,guid=1000  0   0
# a swapfile is not a swap partition, no line here
    • New
    Quote from Fox-Jet

    ... uid=1000,guid=1000 0 0

    Korrigiere mal bitte

    Code
    ,gid=1000
    Quote from Fox-Jet

    Würdest du exFAT einer FAT32 formatierung vorziehen?

    Sorry, kann ich nichts zu sagen, da ich mich nicht mit nicht-Unix-Dateisystemen beschäftige.

    Wenn beide Systeme exFat read-write problemlos können, es stabil ist und es die 4GB-Filesizebeschränkung (oder andere) nicht hat, warum nicht?

    Wenn du nichts zu sagen hast, sag einfach nichts.

    • New
    Quote from Fox-Jet

    Würdest du exFAT einer FAT32 formatierung vorziehen? Unter der Berücksichtigung, dass ich die SSD auch mit Mac-OS und Windows-OS benutzen kann?

    Wenn Du mich fragst, dann weder noch. Du musst ja nicht zu Fuss die SSD zum Windows-/Mac Rechner tragen und dort anschliessen. Dafür gibt es scp, sftp, rsync, ssh, u.A.

    Ein journalisierendes Filesystem, wie Ext4, oder btrfs ist immer von Vorteil.


    Was Du aber verschweigst ist der im Threadtitel enthaltene Bedingung "mit Zugriffsrechten für Docker Container" . Da hast Du in RE: Raspberry Pi 4B startet nach einem reboot von der SSD nicht mehr angeführt, dass Du ein reboot durchgeführt hast, ohne vorher alle Container (manuell) zu schliessen. Dadurch hast Du nicht nur ein paar Blätter, sondern einen ganzen Ast (oder mehrere) am Stamm des Filesystem-Baumes verloren, und die Rekonstruktion aus lost+found ist Dir zu beschwerlich.

    Das kannst Du durch einen "richtigen" Mountbefehl nicht verhindern. Das liegt an Deiner Docker-Installation und der fehlenden/fehlerhaften docker-shutdown.unit (oder wie immer systemd die benennt.).


    Servus !

    RTFM = Read The Factory Manual, oder so

    • New
    Quote from RTFM

    Was Du aber verschweigst ist der im Threadtitel enthaltene Bedingung "mit Zugriffsrechten für Docker Container" . Da hast Du in RE: Raspberry Pi 4B startet nach einem reboot von der SSD nicht mehr angeführt, dass Du ein reboot durchgeführt hast, ohne vorher alle Container (manuell) zu schliessen. Dadurch hast Du nicht nur ein paar Blätter, sondern einen ganzen Ast (oder mehrere) am Stamm des Filesystem-Baumes verloren, und die Rekonstruktion aus lost+found ist Dir zu beschwerlich.

    Das sind 2 Paar Schuhe.

    1. Wie bereits erwähnt habe ich meine Lieder als FLAC file auf einer NTFS Platte vorliegen. Beide Platten am Windows PC anzuschließen und auf die SSD rüber zu kopieren ist der einfachste Weg für mich.
    2. Dass die SSD nur wegen den "nicht heruntergefahrenen Containern" bei dem Reboot beschädigt wurde mutmaße ich nur. Wissen tu ich es nicht. Ich habe sogar ein paar Mal erneut versucht den Fehler zu rekonstruieren und auch als alle Docker-Container an waren ist mir die SSD trotz reboot und einem standard shutdown nicht abgeschmiert! (altes Setup!)
    3. Ich habe alle Files und Ordner im "lost+found" durchgesehen, doch ohne File-Endung wie *.flac, *.mp3, *.jpeg, usw. ist der Aufwand diese Files wiederherzustellen viel größer als einfach die Platte neu zu formatieren und die Datein neu rüber zu kopieren. Ein paar Files aus Paperless-ngx habe ich in der Tat "verloren", diese muss ich nun erneut mühselig aus meinen Mails und Ablagen erneut einlesen.

    Das neue Setup sieht nun so aus, dass ich meine Musik auf der 1TB SSD gespeichert habe und das System läuft auf der 500GB SSD. Docker ist auf der 500GB SSD installiert und hat auf die Musikordner nur read-only Rechte. Sollte die Boot-Partition erneut schaden nehmen (warum auch immer) hoffe ich dass die 1TB SSD von diesem Problem verschont bleibt, da kein DockerContainer auf diese SSD schreibt.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login