Samba im Read-Only-Dateisystem lauffähig machen

  • Hallo und Gruß an alle Forumsmitglieder zu meinem Einstieg hier.


    Nachdem es mir gelungen ist, auf einem Raspi das OS (Bullseye) als Read-Only-System einzurichten, schaffe ich es nicht Samba zum Laufen zu bekommen. Ich will die SD-Karte schonen und habe daher einen USB-Stick mit seinen drei Partitionen als beschreibbare Verzeichnisse eingebunden. Die SD-Karte soll künftig nur noch zum Booten und Starten meiner Anwendungen dienen. Nach dem Booten ins RO-System lassen sich smbd und nmbd nicht starten, sobald ich auf rw mounte, lassen sich beide Dienste wieder von Hand starten. Es hat bisher nicht ausgereicht Verzeichnisse auf dem Stick wie z.B. /var/lib/samba/private anzulegen und symbolische Links dorthin zu setzen. Kann mir jemand helfen, Samba zum Laufen zu bringen?

    Im Voraus danke für Eure Antworten.

  • Das read-only-Filesystem ist ein ganz eigenes Filesystem, das schon im frühen Bootprozess über die im Boot-Verzeichnis generierte Datei "initrd.img ..... overlay" aufgrund eines Eintrages in der cmdline.txt aktiviert wird. Wenn Du das read only (overlay) Filesystem aktiviert hast, kannst Du keine Dateien, auch keine Konfigurationsdateien, im root-Filesystem ändern. Alle Änderungen werden im "upper"-Loop Verzeichnis zwar angezeigt, sind bei einem Neustart aber wieder weg, weil sie tatsächlich nur temporär im Hauptspeicher erstellt werden und nie ins root-Verzeichnis geschrieben werden.


    Du musst daher das read-only-overlay Dateisystem wieder deaktivieren, dann die drei (?) Partitionen zum Mounten in die /etc/fstab eintragen und den Samba Server konfigurieren.


    Erst wenn der Stick Mount und der Samba Server zur Zufriedenheit funktioniert, kannst Du wieder auf das read-only-overlay Filesystem umstellen.


    Servus !


    PS: Links über die Filesystemgrenzen hinaus würde ich jedenfalls vermeiden.

    RTFM = Read The Factory Manual, oder so

  • Mir stellt sich hier die Frage

    Mir stellt sich eine ganz andere Frage.

    Wenn Samba auf der SD installiert und konfiguriert ist, die Partition(en) per fstab gemounted wird (werden) und das Filesystem dann auf ro gesetzt wird, wie von RTFM vorgeschlagen, werden dann die Mountverzeichnisse des Sticks nicht auch auf ro gesetzt?

    Ich könnte mir vorstellen, dass das ganze dann Probleme verursacht und gar nicht funktioniert. (Habe es aber noch nicht ausprobiert)

  • Das über raspi-config aktivierte ro-overlay-Filesystem bezieht sich nur auf das root-Filesystem.

    Gemountete Filesysteme (also Filesysteme ausserhalb des root-FS z.B. /boot) sind weiterhin rw erreichbar.


    Ein SAMBA Share, das auf ein gemountetes Verzeichnis zeigt, ist - wie bisher - rw erreichbar, und es werden auch neue/geänderte Dateien dauerhaft gespeichert. [von der Einstiegshürde, den richtigen UIDs/GIDs, mal abgesehen]



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Nachdem es mir gelungen ist, auf einem Raspi das OS (Bullseye) als Read-Only-System einzurichten, ...

    BTW: Wie ist auf deinem RO-System, die Ausgabe von:

    Code
    sudo blockdev --report

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Danke für Eure Antworten!


    Franjo G :

    glücklicherweise lassen sich die partitionen des sticks beschreiben, obwohl das root-system ro ist, weil ich alles in der fstab als unterschiedliche mount-point definiere.


    @ hyle:

    Die SD-Partitionen /boot und / werden per fstab mit der Option ro gemountet, die Stick-Partitionen als beschreibbare.

    /tmp, /var/log, /var/tmp und /var/cache habe ich in der fstab mit tmpfs gemountet.

    Für Daten gibt es noch /var/www/html/tmp als tmpfs-Ordner. Dadurch können php-skripte unter www-data und ich als pi:(www-data) vom PC innerhalb meines LANs zugreifen.

    Auf dem mit VFAT eingerichteten Stick befinden sich Programme, die ich schön einfach vom PC aus schreiben und per ssh gleich testen kann.


    Wenn ich mit nano eine Datei auf z.B. /home/pi öffne, wird mir auch angezeigt, dass es sich um ein ro-Dateisystem handelt, und ich kann wirklich nichts verändern. Daraus schließe ich, dass ich tatsächlich die SD-Karte nicht mehr mit Schreibaktionen belaste. So habe ich es gewollt.

    Natürlich schalte ich per sudo mount -o remount,rw / ; sudo mount -o remount,rw /boot wieder um, wenn ich etwas verändern will. Das Prinzip habe ich verstanden.

    Dienste wie lighttpd funktionieren ja schon, weil sie ihre protokolle jetzt in die entsprechenden Verzeichnisse im RAM schreiben.


    Mein Problem ist nur, dass ausschließlich Samba nicht anläuft, weil es in Verzeichnissen nach Dateien sucht oder neue Dateien anlegen will.

    Ich würde als nächstes probieren die angemahnten Verzeichnisse beim Booten neu im RAM anzulegen und mich schritt für schritt über noch verbliebene Fehlermeldungen rantasten.

    Ich dachte nur, vielleicht hat jemand von euch dieses problem schon gelöst und gibt mir tipps, welche verzeichnisse und evtl. dateien ich anlegen und/oder verlinken soll.


    Ich weiß nicht, ob man hier im Forum Konsolausgaben reinkopieren darf, aber ich mach das mal jetzt.

    Mit sudo systemctl restart smbd (im ro-Systemzustand) und anschließendem sudo journalctl -xe sieht es so aus (Auszug aus ner langen Liste):

    ...

    ░░ A start job for unit smbd.service has begun execution.

    ░░

    ░░ The job identifier is 3266.

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29, 0] ../../lib/util/debug.c:1104(reopen_one_log)

    Aug 04 15:06:29 zooloo smbd[2669]: reopen_one_log: Unable to open new log file '/var/log/samba/log.smbd': No such file or directory

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29, 0] ../../lib/util/util.c:364(directory_create_or_exist)

    Aug 04 15:06:29 zooloo smbd[2669]: directory_create_or_exist: mkdir failed on directory /var/log/samba/cores: No such file or directory

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29, 0] ../../source3/lib/dumpcore.c:59(get_default_corepath)

    Aug 04 15:06:29 zooloo smbd[2669]: Failed to create /var/log/samba/cores for user 0 with mode 0700

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29, 0] ../../source3/lib/dumpcore.c:256(dump_core_setup)

    Aug 04 15:06:29 zooloo smbd[2669]: Unable to setup corepath for smbd: No such file or directory

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29.554733, 0] ../../lib/util/debug.c:1104(reopen_one_log)

    Aug 04 15:06:29 zooloo smbd[2669]: reopen_one_log: Unable to open new log file '/var/log/samba/log.smbd': No such file or directory

    Aug 04 15:06:29 zooloo smbd[2669]: [2022/08/04 15:06:29.554991, 0] ../../source3/smbd/server.c:1784(main)

    Aug 04 15:06:29 zooloo smbd[2669]: smbd version 4.13.13-Debian started.

    Aug 04 15:06:29 zooloo smbd[2669]: Copyright Andrew Tridgell and the Samba Team 1992-2020

    Aug 04 15:06:29 zooloo systemd[1]: smbd.service: Main process exited, code=exited, status=1/FAILURE

    ...


    Missachtet mal die falschen zeitangaben. die synchronisierung mit der fritzbox läuft noch nicht. ich weiß aber, wie ich es wieder hinkriege...

  • ;) Hallo nochmals.

    Nach weiteren erfolglosen Versuchen habe ich mich für eine krückenhaften Lösung entschieden:

    Mir ging es darum die SD-Karte so weit wie möglich von Schreibzugriffen zu befreien. Dazu wollte ich, wie aus vielen Beiträgen im Netz zu lesen, das root-Verzeichnis über die fstab mit ro mounten. Genau dann funktionierte Samba aber nicht.

    Also habe ich nun die /etc/fstab mit folgenden Zeilen erweitert:


    tmpfs /var/log tmpfs nodev,nosuid 0 0

    tmpfs /var/lib/samba/private tmpfs nodev,nosuid 0 0


    /boot und / werden wieder ganz normal mit Schreibrechten gemountet.


    Ergänzung:

    Es scheint so zu sein, dass die Information über einen smb-user genau in dem verzeichnis .../private enthalten ist. Da dieses Verzeichnis nur temporär existiert, muss der Nutzer nach einem Reboot neu angelegt werden. Ich habe es erreicht mit einem Skript, dass beim Reboot ausgeführt wird:


    echo -e 'Passwd\nPasswd' | smbpasswd -s -a Smbuser

    systemctl restart smbd && systemctl restart nmbd


    Damit habe ich mein Hauptziel der Kartenschonung (nun auch beim Samba-Betrieb) erst mal erreicht.

    Diese Methode erfüllt seinen Zweck, auch wenn sie nicht sehr elegant ist...

    Nochmals Danke für Eure Antworten.

    Vielleicht kann ich ja zu einem späteren Zeitpunkt mal etwas nützliches beitragen...


    Ich sollte wohl jetzt den Thread als erledigt markieren.

  • Was hältst Du davon, wenn Du einfach Dein Samba inkl. User im rw-System einrichtest und danach per sudo raspi-config >> Performance Options >> Overlay File System das OverlayFS aktivierst? Damit musst Du auch keine komplzierten Verrenkungen in der /etc/fstab machen. ;)


    Ich dachte eigentlich meine Beiträge waren "Wink mit dem Zaunfeld" genug. :conf: Sorry, falls nicht!

  • Hallo Hoschi,

    ich weiß leider nicht, was ein overlay file system ist. Bin froh überhaupt mit dem raspi umgehen zu können, lerne aber täglcih dazu...

  • ich weiß leider nicht, was ein overlay file system ist.

    Das ist genau das was Du suchst. :cool: Es wird nicht auf die SD-Karte geschrieben. Es handelt sich um ein virtuelles Dateisystem, bei dem zur Not auch einfach der Stecker gezogen werden kann, ABER das betrifft nur das System, keine externen Laufwerke.


    Mach Dir Notizen zu Deiner jetztigen Konfiguration und diese danach rückgängig und versuchs mal mit meinem Vorschlag aus Beitrag #10! Falls da etwas nicht so funktionieren sollte wie Du Dir das vorgestellt hast, dann kannst Du ja zur Not wieder das aus Beitrag #9 einstellen. ;)



    Btw.

    Hallo Hoschi

    Mein Username ist hyle, habe aber kein Problem, wenn man mich Hoschi nennt! :D

  • Gut.

    Habe gerade einen alten Artikel (https://www.linux-magazin.de/ausgaben/2017/06/kern-technik/) dazu gelesen. Klingt interessant, ist aber für mich nicht so leicht zu verstehen. Woher weiß z.B. dieses System, dass nur die SD-KArte gesperrt sein soll, der USB-Stick aber nicht?

    Du musst nicht darauf antworten! Ich lese morgen, wenn ich ausgeschlafen bin, den ganzen Artikel nochmal. Dann bleibt mehr haften.


    Gute Nacht.

  • Gut.

    Habe gerade einen alten Artikel (https://www.linux-magazin.de/ausgaben/2017/06/kern-technik/) dazu gelesen. Klingt interessant, ist aber für mich nicht so leicht zu verstehen. Woher weiß z.B. dieses System, dass nur die SD-KArte gesperrt sein soll, der USB-Stick aber nicht?

    Du brauchst Dich nicht mit der verlinkten Anleitung aus dem Jahre 2017 quälen. Inzwischen wurde das Read Only Overlay Filesystem in die Konfigurationsdateien des Pi aufgenommen.

    In raspi-config unter den Performance Options,

    in ( Einstellungen-) Raspberry-Pi-Konfiguration unter Leistung - Overlay Filesystem


    Es wird nur das root Filesystem, also /dev/mcblk0p2 als Overlay Filsystem übernommen, alle davor gespeicherte Konfigurationen werden ausgeführt, alle danach durchgeführte Änderungen gehen beim nachfolgenden Shutdown/Reboot verloren. Es gibt keine Möglichkeit auf das auf der SD befindliche Filesystem schreibend zuzugreifen. Alle gemounteten Filesysteme bleiben von der Beschränkung unberührt. Linux erkennt ein gemountetes Filesystem am (aktiven) Mount.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo hyle & RTFM,


    das ist ja 'n Hammer!

    Ich habe Eure Tipps ausprobiert, also das Overlaysystem über raspi-config installiert und dann alles auf gewünschtes verhalten getestet.

    Funktioniert alles einwandfrei :bravo2:

    Samba-Zugriffe funktionieren, HTML- und PHP-Skripte werden vom Browser vom PC aus gefunden und ausgeführt, SSH klappt sowieso.

    Die fstab ist stark vereinfacht und baut nur zusätzlich ein /temp im tmpfs, so dass dort Dateien abgelegt werden können, egal ob von außen über Samba, durch PHP-Skripte oder Python-Programme. So wollte ich es. Super!

    Das Ganze benutze ich, um meine selbstgeschriebene Heimautomation zu betreiben.

    Bisher war eben nur die Gefahr, dass der RasPi irgendwann durch SD-Karetndefekt oder Stromausfall nicht weider den Hintrn hoch kriegt.

    Ich denke, diese Gefahr ist nun viiiiiiiiel kleiner.

    Dass alles vom tmpfs beim Reboot weg ist, weiß ich. Deshalb schreibe ich auch zyklisch wichtige Daten auf einen externen Speicher.


    Nochmals :danke_ATDE: an Euch.


    Gibt es eigentlich eine elegante Möglichkeit vom ovl- wieder ins rw-System zu kommen ohne immer den raspi-config-Dialog durchspielen zu müssen?

    Könnte es nicht reichen die letzte Zeile der config.txt auszukommentieren und cmdline.txt ohne den ersten Ausdruck zu verwenden?

    Bliebe dann nur noch ein Reboot als Aktion übrig.

    Wenn das so geht, würde ich alles in ein Skript packen, z.B. mit dem Namen "boot-rw".

    Was haltet Ihr davon?

  • daxb:

    Das glaube ich nicht, da das Original-Verzeichnis / ja nicht mehr ansprechbar ist, wegen des überlagerten Dateisystems.

    das mit dem remount ro / rw hatte ich vorher genutzt, als ich noch kein overlaysystem betrieben hatte.