Aber solange mir erstes nicht gelingt, geht das leider nicht.
Das sollte sich alles mit einem passenden
bind-Mount für das Verzeichnis, wo die standardmäßig gespeichert werden, regeln lassen. Schau Dir mal die "Theorie" von solchen Mount-Vorgängen an. Lediglich die erste Verzeichnisebene (hier
/opt, soweit ich weiß) muß schon existieren, der ganze Rest läßt sich dann passend zur Laufzeit einrichten. Wenn man eine "tiefere" Verzeichnisebene braucht, die man nicht auf dem NAS-Speicher haben will (man kann natürlich auch ein Verzeichnis
opt unter
/var/media/ftp anlegen und das dann direkt über
/opt mounten), dann mountet man unter
/opt eben erst mal ein
tmpfs und erzeugt dort den benötigten Pfad, in den man dann an der passenden Stelle wieder das Verzeichnis auf dem NAS-Speicher einblendet. Man braucht sich um wiederholte Mounts für ein
tmpfs auch keine Gedanken zu machen - jedes davon belegt nur soviel Hauptspeicher, wie die darin erzeugten Inodes und Daten benötigen, also praktisch gar nichts, wenn man darin nur irgendwelche passenden Pfade erzeugt.
Wer das also auch ohne USB-Stick realisieren will, braucht nur etwas wie das hier:
Bash:
mount -t tmpfs tmpfs /opt
mkdir /opt/rustdesk
mount -o bind /opt/rustdesk /var/media/ftp/rustdesk
Jedenfalls solange es nichts vorher in
/opt gab - denn das würde danach nicht mehr vorhanden sein für das System. Dabei können dann natürlich unter
/var/media/ftp/rustdesk problemlos die Binaries und weitere Verzeichnisse (u.a. für die Logs, wobei ich die eher ins
tmpfs unter
/var/log schreiben lassen würde, auch wenn sie dann beim Neustart weg sind) liegen. Ja, sogar "feste" Symlinks unterhalb von
/opt im SquashFS-Image, die auf Verzeichnisse im NAS-Speicher verweisen, sollten funktionieren, solange sie bereits beim Image-Build hinzugefügt werden. EDIT: Dabei muß man dann natürlich wieder dafür sorgen, daß der NAS-Speicher auch "executable" ist, wenn man die Binaries dort ablegt.
Es gibt also eigentlich gar keine Notwendigkeit, den Binaries irgendwie die Speicherung der Daten an einer anderen Stelle beizubringen - anstatt die Binaries an die Dateisystemstruktur anzupassen, kann man genauso gut die passende Dateisystemstruktur erzeugen, die von den Binaries "erwartet" wird. Dann muß man halt das Ganze wieder über einen passenden Service anschubsen - das ist ohnehin besser (dann kann man nämlich darauf verzichten, irgendwelche Skripte von USB-Speicher zu starten) und man kann sogar noch ohne Kopfstände mit 10 oder 30 Sekunden dafür sorgen, daß die Services in der richtigen Reihenfolge gestartet werden. Würde ich das implementieren wollen, wären das drei Services - einer zum Einrichten der passenden Umgebung (der muß auch nicht erneut gestartet werden, wenn er beendet ist) und für jedes der beiden Server-Binaries jeweils einen weiteren, die auf die Einrichtung der Umgebung durch den ersten warten. Wovon man diesen dann wieder abhängig macht (ich würde ihn zu den Netzwerk-Services zählen wollen), muß man nur gucken.
Und den automatischen Neustart, wenn einer der Services unerwartet beendet wurde, erhält man damit auch gleich noch - schaut man in die AVM-Services, sind mind. die Parameter
Restart und
RestartSec auch im AVM-
systemd implementiert. Was die bedeuten, findet man in der
systemd-Hilfe:
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
