Da dürfte das System aber niemals vorbeikommen, solange niemand die "mod.cfg" geändert hat:
https://github.com/Freetz/freetz/blob/master/make/mod/files/root/etc/default.mod/mod.cfg#L27
Der Standardwert ist nun mal "link" - und damit werden die "embedded files" auch genutzt (der "if"-Zweig, denn das ist dann eben nicht "copy"). Wenn hier aus irgendwelchen Gründen kein "link" für "MOD_EXTERNAL_BEHAVIOR" gesetzt sein sollte (kriegt man mit einem einfachen "env" in der Shell heraus), dann muß es dafür ja einen Grund geben und der liegt ziemlich sicher nicht in dem verwendeten Image, denn dort wird lt. ".config" ja nichts "externalisiert".
Also tippe ich mal - als naheliegendste Vermutung - auf eine alte Freetz-Konfiguration, die hier irgendwo eingespielt wurde und von einer Version mit "externals" stammte oder irgendjemand hat (dann halt "etwas wild" und ohne Plan) an der Variablen "MOD_EXTERNAL_BEHAVIOR" gedreht - zumindest dann, wenn die eben nicht auf "link" stehen sollte.
Ergo ... der erste Schritt zu einer Erklärung wäre es, den aktuellen Wert dieser Variablen im laufenden System zu erkunden. Danach kann/muß man dann überlegen, wie es zu dem Wert kam bzw. warum sich das Skript "rc.samba" bei korrektem Wert falsch verhält (was ja deutlich unwahrscheinlicher wäre als ein falscher Wert).
Ich benutze zwar kein Freetz, aber meines Wissens wird auch die "mod.cfg" (bzw. deren Änderungen, weil das ja alles nur als "diff" zu den Standardeinstellungen gesichert wird) in ein Backup der Freetz-Einstellungen eingeschlossen:
https://github.com/Freetz/freetz/bl...root/usr/mww/cgi-bin/backup/do_backup.cgi#L26 und das wäre zumindest mal ein (plausibler) Weg, wie aus dem Standardwert "link" (den man sich in der "/etc/default.mod/mod.cfg" in seinem Image auch jederzeit ansehen kann - der ist dort ja "read-only" verankert) am Ende der Wert "copy" werden sollte - sofern die Annahme der "fehlerhaften Stelle" in "rc.samba" aus #7 stimmen sollte.
Da es auch nur dann in den "else"-Zweig geht, wenn der Wert "copy" sein sollte, kommen andere Erklärungen (wie die Vermutung, die Variable wäre aufgrund eines Fehlers gar nicht gesetzt) ja auch eher nicht in Frage bzw. es bräuchte schon sehr krude Umstände, damit die Ursache sich darin "versteckt".
Da die einzige Möglichkeit, diesen Wert "umzuschalten", auch noch in der "externals"-Konfiguration von Freetz steckt (
https://github.com/Freetz/freetz/bl...t/usr/lib/cgi-bin/mod/conf/40-external.sh#L12) und diese bei der gezeigten ".config" gar nicht erreichbar sein sollte (beide "EXTERNAL"-Symbole in Zeile 12 sind Variablen aus der ".config" und dort nicht enthalten, die KÖNNEN also gar nicht beide auf "y" stehen und zum Einschluß der Radiobuttons führen), bleibt fast nur noch die Schlußfolgerung von oben übrig, daß hier eine ältere Freetz-Konfiguration (aus einer Version, in der es "externals" gab) importiert wurde, ohne das "zu erwähnen".
Sollte ich mich da irren, wäre ich auf die Erklärung, wieso es ansonsten zum "else"-Zweig kommen sollte (immer noch unter der Voraussetzung, daß das tatsächlich die korrekte Annahme ist), sehr gespannt. Aber auch hier zeigt sich wieder, daß man zuerst mal den aktuellen Wert von "MOD_EXTERNAL_BEHAVIOR"
kennen muß, bevor man sich an die weitere Ursachenforschung macht.
-------------------------------------------------------------------------------------------------------
Daß sich eine Datei im SquashFS-Image nicht einfach editieren läßt, ist "Absicht" von dessen Entwicklern und es gibt eigentlich auch keinen plausiblen Grund (wenn ich den nur übersehen sollte, lasse ich mich gerne korrigieren), solches anzustreben. Hier ist ja eher nicht die Datei defekt (zumindest mit sehr hoher Wahrscheinlichkeit), sondern das Drumherum - was aber auch deutlich naheliegender ist und damit der primäre Verdacht sein sollte, anstelle der Annahme, daß alle anderen Benutzer des Samba-Pakets in Freetz nur zu doof wären, das selbst zu bemerken.
Insofern macht das Ansinnen, die "rc.samba" editieren zu wollen, um sie zu "korrigieren", für mich ohnehin keinen wirklichen Sinn bzw. das sollte für NIEMANDEN, der sich mit Freetz nicht
wirklich exzellent auskennt, die
allererste Wahl sein. Ich finde es generell sehr viel logischer, wenn man erst einmal
sein eigenes Vorgehen auf mögliche Fehler und Irrtümer abklopft, anstatt in der angebotenen Lösung (solange man nicht wirklich, wirklich ein "early adopter" ist und zu den echten Pionieren beim Einsatz irgendeiner Software gehört) nach dem Haar in der Suppe zu suchen. Solche gibt es zweifellos auch (und oft genug) ... aber es ist nicht immer gesagt, daß sie vom Haupt (hoffentlich) des Kochs stammen müssen.
Sicherlich gibt es auch in Freetz noch Fehler ... die Wahrscheinlichkeit, daß man als Allererster über einen solchen stolpert, ist aber eher gering - zumindest wenn man sich den zeitlichen Abstand zum Erscheinen der verwendeten FRITZ!OS-Version ansieht, denn in der Zwischenzeit haben sicherlich schon einige Freetz-Benutzer ein Image auf der Basis der 07.01 gebaut - auch wenn diese (wie alles jenseits des "responsive design") deutlich als "(HIGHLY) EXPERIMENTAL" gekennzeichnet ist (afaik und nach dem hier:
https://github.com/Freetz/freetz/blob/master/config/ui/firmware.in#L362).
PS: Bei Freetz schreibt sich BEHAVIOR eher britisch, also mit zusätzlichem "U" vor dem "R" - falls jemand mit Linux-Kommandos danach suchen sollte (ich habe es oben in der amerikanischen Form verwendet, was dann natürlich nicht paßt).
