Ich war (absichtlich) am Beginn "kurz angebunden", eben weil ich nicht das ganze Problem "analysieren" und damit irgendeine "Verantwortung" für die Lösung übernehmen will.
Die Bemerkung hinsichtlich der "einfachen Version" der Support-Datei verstehe ich nicht ... wenn das eine "Begründung" sein sollte, warum die in #5 so kurz ist, erklärt das absolut nichts. Die "Gegenprobe", die ich mit der 7390 ohne Freetz gemacht hatte, war ja (erkennbar) auch nur die "einfache Version", denn von der Sektion mit den TFFS-Daten ist da ja nichts zu sehen.
Ich bleibe aber dabei, daß dieser Thread m.E. nichts im "unmodifizierten" Teil zu suchen hat ... und daß die Angaben zur Freetz-Konfiguration immer noch fehlen, wiederhole ich auch - wenn auch ungern, weil ich mich wie eine kaputte Schallplatte fühle.
Bei der 7390 gibt es ja den "nmbd" nicht mehr (solange man ihn nicht selbst wieder hinzufügt) und da der "smbd" nur über den "inetd" gestartet wird, wenn ein Client einen Verbindungsversuch startet, ist es erst einmal durchaus "normal", wenn in der Prozessliste kein Samba-Server zu sehen ist. Warum der dann nicht startet, wenn ein Zugriff erfolgt (und wenn die Namensauflösung nicht funktioniert, verwendet man eben einfach mal die IP-Adresse zum Test), sieht man auf der "console" aber auch viel besser (und vor allem "live"), als in so einer Support-Datei.
Es macht also nur wenig bis gar keinen Sinn, sich bei einer Box mit Freetz und einem Shell-Zugang bei der Fehlersuche auf die Support-Datei zu stürzen, wenn man es auch viel einfacher haben kann. Hier startet man mit einem Blick in die "inetd.conf" und in die Ausgabe von "netstat" ... und wenn da dann der Samba-Server eingetragen ist und der "inetd" auf dem passenden Port "lauscht", kann man eine Verbindung mit seinem SMB-Client versuchen ... dabei beobachtet man dann die Ausgaben im Terminal und ggf. auch die im Syslog - irgendwo sollte sich schon eine Fehlernachricht materialisieren, wenn der "smbd" nicht gestartet werden kann.
Wobei ich - rein aus dem Bauch - eher darauf tippen würde, daß der Samba-Server hier gar nicht aktiviert wird (also nicht in der "inetd.conf" steht) ... ob die Einstellungen diesbezüglich überhaupt stimmen (die "Anzeige" im GUI kann ja auch trügen), sieht man ja wieder nicht, weil die "usb.cfg" (die auch in der Support-Datei gestanden hätte) fehlt.
Es macht den Eindruck, als wäre die NTFS-Partition tatsächlich gemountet (ob fehlerfrei oder nicht, ist dabei erst mal egal) und nach den anderen Angaben zum NAS zu urteilen, mußte auch das Basisverzeichnis "/var/media/ftp" zumindest für den Benutzer "ftpuser" freigegeben sein (für den anderen aber schon mal nicht) ... aber es ist auch ebenso unübersehbar, daß bei einem Mountpoint "uStor01" und dem Fehlen dieses Labels für das NTFS-Volume, das Mounten über die Freetz-Skripte erfolgt sein MUSS und nicht über die Originale von AVM. Die würden nämlich einen gänzlich anderen Pfad benutzen, sofern das Label nicht gesetzt ist (oder die entsprechende Einstellung dazu in der "usb.cfg" nicht vorhanden ist - diese hat auch keine Entsprechung im GUI).
Aber auch die Tatsache, daß nach Deinen Angaben der Samba-Service im AVM-GUI nicht deaktivierbar ist, zeigt deutlich, daß hier etwas nicht stimmt ... was das jetzt genau ist, wird sich vermutlich (für diese uralte Box) auch niemand bei Freetz noch eingehend ansehen - die generelle Empfehlung ist es ja eigentlich, auf die Verwendung von "remove patches" (von denen Du aber rege Gebrauch gemacht hast, wie man in Ansätzen in der ersten Support-Datei schon sehen konnte) ab FRITZ!OS 06.5x einfach zu verzichten. Platzproblemen in der 7390 kann man mit "externals" entgegenwirken (das ist bei Dir sogar vorhanden) und seitdem AVM die WLAN-Treiber in ein Plugin ausgelagert (und damit wieder Platz im NOR-Flash geschaffen) hat, kriegt man die zusätzlichen Dateien für die Verwendung von "externals" bei Freetz auch wunderbar in das SquashFS integriert nach meiner Erfahrung ... und zwar auch ohne "remove patches".
-----------------------------------------------------------------------------------------------------
Was noch auffällt ist, daß bei AVM eben "/sbin/blkid" ein Symlink auf "/usr/sbin/blkid" ist und AVM bis 07.19 in der "/bin/supportdata.usb" immer eine Zeile
Code:
test -x /sbin/blkid && /usr/sbin/blkid
verwendete, die auf den ersten Blick halt "unlogisch" aussieht ... das Programm "blkid" wird aber auch beim Mounten von Volumes benötigt (da wird es über "/sbin/blkid" aufgerufen in den AVM-Dateien) und Freetz verändert hier ganz offensichtlich etwas an der Verteilung der Dateien, denn anders ist die Zeile
Code:
/bin/supportdata.usb: line 6: /usr/sbin/blkid: not found
in Deiner Datei nicht zu erklären.
Nun mag es ja sein, daß das "blkid" in "/sbin" weiterhin das "originale" ist ... irritierend ist es trotzdem und außerdem ist es (wenn man mit AVM kommuniziert und dabei auch nur "Auszüge" aus der Support-Datei verwendet, auch wenn man das bei AVM gar nicht gerne sieht) "sehr verräterisch". So mancher hat sich schon gefragt, wie AVM wohl bemerkt hat, daß er mit einer modifizierten Firmware arbeitet ... das sind dann solche "kleinen Ungenauigkeiten", die den Unterschied machen und dem erfahrenden Support-Datei-Leser mehr erzählen, als dem Besitzer manchmal lieb ist.
-----------------------------------------------------------------------------------------------------
Wie auch immer ... meine Hinweise sollten nur Hilfe zur Selbsthilfe sein und ich möchte gar nicht, daß sich jetzt hier ein Dialog der Form: "Sag' mir, was ich machen/gucken/probieren soll." entwickelt. Ich würde Dir - unabhängig davon - empfehlen, einen Moderator darum zu bitten, diesen Thread nach "Modifikationen" zu verschieben ... Deine Annahme, daß Dein Freetz generell nichts am NAS ggü. der originalen Firmware verändert hätte, ist jedenfalls falsch und dabei habe ich durchaus zur Kenntnis genommen, daß es vor einer Woche noch funktioniert haben soll und Du seitdem keine neue Firmware installiert hat.
Die offensichtlichsten Punkte, woran so etwas liegen könnte, habe ich versucht aufzuzeigen. Wenn alle anderen Angaben zu "keine Änderungen" und "Volume getestet" (und nicht nur abgezogen und neu angesteckt, denn ich schrieb ja ausdrücklich in #2, daß das extern getestet (und natürlich bei Bedarf auch repariert) werden sollte - die FRITZ!Box hat die notwendigen Tools für eine Reparatur nicht an Bord) tatsächlich stimmen und da nicht nur etwas vergessen oder als unwesentlich beiseite geschoben wurde, sollte der Service auch benutzbar sein ... wobei auch Windows-Updates u.ä. oder abweichende Netzwerkadressen (usw., usf. - es gibt jede Menge weitere Möglichkeiten für Fehler) in solche "Überlegungen" eben einfließen sollten und da kann ich mir heutzutage etwas in der Art: "Es wurde DEFINITIV nichts geändert." eigentlich kaum noch vorstellen - niemand hat bei sich ALLE Komponenten des Heimnetzes heute noch in dieser Weise unter Kontrolle.
Es hilft also alles nichts ... da wirst Du selbst "ran müssen". Die Hinweise, wo Du als nächstes suchen solltest/könntest, hast Du erhalten ... nun mach (selbst) was draus. Im einfachsten Fall ist es tatsächlich nur der Tatsache geschuldet, daß aus irgendwelchen Gründen der (NetBIOS-)Name "fritz.box" nicht aufgelöst werden kann oder irgendwo in die Wüste zeigt ... die Nachricht in Windows differenziert (iirc, wobei auch die Angabe, welches Windows das hier ist, ja irgendwie fehlt) nicht zwischen "Ich kenne den Namen nicht." und "Ich kann den Host nicht erreichen." - aber das ist ja mit einem Handgriff zu ergründen (ggf. mit ein paar mehr, wenn man sich erst im Internet informieren muß, wie man eine Adresse anstelle eines (NetBIOS-)Namens angibt - aber dabei findet man nebenbei noch viele andere nützliche Informationen und weil ich Dir diese vielen Möglichkeiten bei tatsächlich vorhandener Unkenntnis nicht durch einen Spoiler verderben will, verzichte ich auch bewußt auf diese Angabe und gehe einfach mal davon aus, daß Du es ohnehin schon weißt).
