Was fällt daran auf?
Die verwendete Konfiguration muß schon ziiiiemlich alt sein, wenn da noch ein
volume_labels = no; gesetzt ist. Der Standard da wäre schon seit 06.3x jedenfalls
yes und der ist (m.W.) auch nicht über das GUI zu verändern. Daher würde man hier (wenn er nicht von Hand gesetzt wurde und da wäre die Frage, warum man das machen sollte) annehmen, daß diese FRITZ!Box-Konfiguration schon ein paar Jahre auf dem Buckel hat und nicht direkt auf dieser 7590 "frisch" aufgesetzt wurde.
Das Problem mit den Ports habe ich nur versucht zu erklären - das ist ZU ERWARTEN, wenn da der Server-Prozess nicht läuft. Wenn in der Prozessliste kein
nqcs auftaucht, läuft der halt auch nicht - bleibt die Frage, warum das so ist. Ein "echter" Absturz des Daemons sollte eigentlich seine Spuren hinterlassen (spätestens in der Support-Datei beim nächsten Booten), denn dann würde man (bzw. ich) eine
crash.log-Ausgabe in der Datei erwarten (nicht zu verwechseln mit einer
panic.log, wo die Box dann neu startet). Also kommt der Prozess vermutlich nicht mal bis dorthin bzw. "beendet" sich einigermaßen regulär (d.h. ohne "Absturz"), was eine fehlerhafte Konfiguration noch wahrscheinlicher macht.
Was könnte man als nächstes testen?
Erst einmal würde ich den USB-Stick von Sandisk abziehen ... der SMB-Zugriff funktioniert (wenn er denn klappt) auch mit dem internen NAS-Flash. Das schließt nicht nur Probleme mit dem Pfad beim Mounten aus (
SanDisk-UltraUSB3-0-01), sondern auch noch potentielle NTFS-Probleme im Dateisystem auf diesem Stick.
Dann würde ich einfach den Server-Namen mal auf den "Standardwert" stellen bzw. auf einen, der tatsächlich "rein ASCII" ist - die Betonung, daß der UTF-8-kompatibel wäre, läßt ja immer noch irgendwelche Sonderzeichen (bis hin zu deutschen Umlauten) offen. Im Bemühen, alle möglichen Fehlerquellen auszuschließen bzw. diese zu minimieren, würde ich da etwas Simples wie
FB7590 verwenden.
In einer neu gestarteten Box (unter Berücksichtigung der o.a. zwei Punkte) dann erst mal nach dem Server sehen und wenn der immer noch nicht will, die Support-Datei noch einmal speichern. Wie ich oben schon angeführt habe, verwendet der
nqcs eine Konfigurationsdatei unter dem Pfad
/tmp/nq/config und da
/tmp nur ein Symlink nach
/var/tmp ist, sollte das Verzeichnis mit dieser Konfiguration auch irgendwo in der Support-Datei zu finden sein. Dort steht zwar vermutlich auch kein Inhalt dieser Datei, aber schon ihre Existenz (oder auch ihr Fehlen) kann einen Hinweis darauf liefern, ob das Start-Skript für den Server (
/etc/init.d/rc.smb2):
Code:
#!/bin/sh
NAS_ENABLED=$(echo usbhost.nas_enabled | usbcfgctl -s)
ENABLED=$(echo usbhost.samba_server_enabled | usbcfgctl -s)
if [ "$NAS_ENABLED" != "yes" ] || [ "$ENABLED" != "yes" ] ; then
exit 0
fi
# config file for nqcs
CONF_DIR=/tmp/nq
CONF_FILE=${CONF_DIR}/config
mkdir -p $CONF_DIR
rm -f $CONF_FILE
samba_config_gen > $CONF_FILE
# has hardcoded pathes to the config file
exec nqcs
überhaupt aufgerufen wurde und wo es vielleicht zum Problem kam.
Das
samba_config_gen ist z.B. ein Programm von AVM, was die erwähnte
config erst erstellt - wenn das aus irgendeinem Grund ein Problem hat, wird der
nqcs auch nichts machen, weil ihm einfach seine Konfiguration fehlt. Aber dann würde zumindest das Verzeichnis schon existieren, denn das wird ja (zwei Zeilen darüber) mit dem
mkdir angelegt.
Das muß zwar alles nicht sofort zu der Erkenntnis führen, worin das Problem besteht, aber man kann es auf diese Weise Schritt für Schritt weiter eingrenzen, indem man erst einmal den gesamten USB-Teil aus dem Spiel nimmt und die Konfiguration auf das wirklich Notwendige beschränkt. Klappt es damit auch noch nicht, muß man weiter suchen - ansonsten hat man die Ursache des Problems schon mal eliminiert und kann dann - in kleinen Schritten - wieder zur ursprünglichen Konfiguration zurückkehren, bis das Problem dann doch wieder auftritt (oder auch "rätselhafterweise" komplett verschwunden ist und nicht wieder auftauchen mag).
Im nächsten Schritt (wenn die vorherigen nichts bringen) würde ich dann mal eine "frische"
usb.cfg verwenden - entweder durch eine Neukonfiguration der Box oder durch das Löschen der
usb.cfg in einer (neu erstellten) Sicherung und den Re-Import derselben nach dieser Änderung (was ein paar zusätzliche Handgriffe braucht, damit die geänderte Datei akzeptiert wird - das ist hier aber mehrfach ausführlich beschrieben, wie man so eine Sicherungsdatei bearbeiten kann/muß). Das "löst" nicht nur die Sache mit dem
volume_labels = no; auf, sondern man kriegt auch den Standardnamen für den Server auf diesem Weg wieder eingestellt. Ich sehe zwar beim Vergleich der Daten oben auch nichts, was sofort ins Auge fallen würde ... aber ich weiß auch nicht, was am Ende das
samba_config_gen stören könnte (und das ist derzeit die Stelle, wo ich das Problem vermuten würde). Mit etwas Pech ist das sogar der Wert
NAS für den Share-Namen - wenn meine Vermutung hinsichtlich der Quelle des Problems stimmen sollte, ist sogar die Versionsabhängigkeit des Problems nicht mehr sooo überraschend, denn dieses Programm wird von AVM sicherlich (anders als die Quellen für den SMB-Server von einem Drittanbieter) eher auch mal geändert. Da hier auch noch die Daten für die Benutzer herangezogen werden, um die erwähnte
config zu erstellen (die sähe in etwa so aus:
Code:
{
"workgroup": "FB7490",
"share": "FB7490",
"server_comment": "FB7490",
"v1_enabled": false,
"users": [
{
"name": "TEST_UPNP",
"id": 10,
"password": "a/[...]q9c=",
"smb_allowed": false
},
{
"name": "FTPUSER",
"id": 12,
"password": "/e[...]U0=",
"smb_allowed": true
},
{
"name": "CENTRAL",
"id": 11,
"password": "kz[...]7k=",
"smb_allowed": false
},
{
"name": "USER_X",
"id": 98,
"password": "gG[...]Os=",
"smb_allowed": true
}
]
}
), ist eine Änderung an diesem Programm auch für die neue Version seehr wahrscheinlich, denn schließlich hat sich auch die Benutzerverwaltung deutlich verändert.
Und so wäre dann auch die Liste der Benutzer der übernächste Punkt, den ich auf dem Zettel hätte ... wenn man nicht komplett neu konfiguriert hat, sollte man dann zumindest mal alle Benutzerkonten löschen (außer dem aktuell verwendeten, was ohnehin nicht geht), ein neues (regelkonformes) Admin-Konto anlegen, von diesem aus auch noch das verbliebene alte Konto entfernen und dann die benötigten Konten noch einmal neu einrichten - vielleicht auch vor dem Neuanlegen von Benutzern erst noch mal mit dem einen Admin-Konto testen, ob der Server dann verfügbar ist.
Noch mehr "Eventualitäten" aufzuzählen, macht dann auch keinen Sinn mehr ... jetzt wärst Du erst mal wieder an der Reihe (wenn Du das Problem lösen willst) mit der Umsetzung der bisherigen Vorschläge.
