Fritzbox 7590 - SMB gelegentlich und hartnäckig "Connection refused"

gimnasia

Neuer User
Mitglied seit
24 Mrz 2013
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hallo 7590-Intensivnutzer,

kennt Ihr das Phänomen, dass SMB mit der Fritzbox 7590 plötzlich nicht funktioniert - und dann ums Verrecken nicht mehr läuft? Bei mir passiert das gelegentlich und ich habe keinen Ansatz. Es scheint irgendwie zu passieren, wenn ich SMB nutze und währenddessen oder vorher als Admin im Webinterface angemeldet war.

Ich greife via Smartphones (Totalcommander LAN-Plugin, Foldersync Pro - jeweils SMB2) zu. Daneben auch mit einem PC.

Timeout auf allen Geräten.

Der PC sagt, nach gewisser Wartezeit:

Zitat:
C:\Users\Michel>net use * \\192.168.42.1\minna
Systemfehler 53 aufgetreten.

Der Netzwerkpfad wurde nicht gefunden.

Foldersync auf dem Androiden sagt:
Zitat:
Failed to connect to /192.168.42.1 (port 445) from /192.168.42.99 (port 58787) after 5000ms: isConnected failed: ECONNREFUSED

Nun, die Box lebt, anpingen kann man sie, die SMB-User sind weiterhin konfiguriert wie immer... aber via SMB kommt kein Gerät mehr dran. Egal welcher der eingerichteten SMB-User genutzt wird. Das Komische: auch nach einem Neustart der Fritzbox nicht mehr.

Übrigens gerade jetzt auch nach Firmware-Update und Neustart - keine Chance mit SMB. Auch die Endgeräte kann ich neu starten, es bringt dann nichts.
Auch habe ich mal den Zugriff auf NAS-Inhalte dem SMB-User entfernt, gespeichert, dann wieder hinzugefügt. So dass sozusagen die Karten mit SMB neu gemischt werden. Bringt aber nichts. Kein Connect.

Irgendwann wird es wieder funktionieren, aber die Umstände sind unklar. Beim letzten Mal dachte ich, es behob sich durch Fritzbox-Neustart - der hilft jetzt aber nicht.

Es steckt auch ein USB-Stick in der Box. Ich habe manchmal den Eindruck, die Fritzbox hat eine Abneigung dagegen.

Also, wer hat sowas noch erlebt?

Danke
 
Zuletzt bearbeitet:
Hallo, ich habe erstmal ein paar Fragen:
  1. Welche Firmeware-Version läuft denn auf der Box?
  2. Steckt neben dem USB-Stick noch etwas an der Box?
  3. Wie kommst du zu dem Eindruck, dass die Fritzbox eine Abneigung gegen den USB-Stick hat?
  4. Zeigt das Ereignis-Log irgendwelche zugehörigen Meldungen?
  5. Bedeutet das Geschriebene, dass du einmal SMB nutzen konntest und seitdem Fehler nicht (nie) mehr?
 
Zuletzt bearbeitet:
  • Like
Reaktionen: gimnasia
  • Like
Reaktionen: gimnasia
Hallo, ich habe erstmal ein paar Fragen:
  1. Welche Firmeware-Version läuft denn auf der Box?
  2. Steckt neben dem USB-Stick noch etwas an der Box?
  3. Wie kommst du zu dem Eindruck, dass die Fritzbox eine Abneigung gegen den USB-Stick hat?
  4. Zeigt das Ereignis-Log irgendwelche zugehörigen Meldungen?
  5. Bedeutet das Geschriebene, dass du einmal SMB nutzen konntest und seitdem Fehler nicht (nie) mehr?
1. 7.2.7 seit heute. Problem trat heute vor dem Update auf und bleibt danach bestehen.
2. Nein
3. Den Kommentar hätte ich mir sparen können, hat weder Hand noch Fuß. Streichen. Bringt nix. War so ein Eindruck, den ich noch mit der 7490 hatte, dass ein USB-Stick manchmal die Box instabil machte.
4. Nein, nichts dazu.
5. Ich konnte SMB seit Wochen nutzen. Wenn dann dieser Fehler auftritt, überhaupt nicht mehr. Dann geht es irgendwann wieder.

- Ich habe auch testhalber das Android-Handy als Heimnetzgerät aus dem Mesh entfernt, ihm eine permanente (andere) IP zugewiesen, neu verbunden - hilft auch nicht.
- SMB aus/ein bzw. NAS aus/ein ändert auch nichts.
- Neuen Testnutzer mit Zugriff auf NAS angelegt, klappt auch nicht.

Das Problem scheint definitiv schon vor der Auth, also auf Connect-Ebene zu liegen.

SMB1 verwenden: OK, habe ich in der Box jetzt aktiviert. Kriege keinen Connect.

Foldersync sagt: Failed to connect: 0.0.0.0<00>/192.168.42.1
Letztere IP der Box ist korrekt.
 
Zuletzt bearbeitet:
Läuft wieder. Habe unter Heimnetz/Usb:

1. Speicher/NAS für eine Minute deaktiviert, dann aktiviert.
2. Den Button "Aktualisieren" (direkt über "Online-Speicher Einstellungen") gedrückt.
 
Zuletzt bearbeitet:
Ich habe bei einem Benutzer, den ich für SMB nicht nutze, eine Änderung vorgenommen.
Jetzt funktioniert SMB wieder nicht.

Das war auch mein Eindruck. "Mach irgendwas bei den Nutzern, danach ist SMB erstmal kaputt". Vorbeschriebene Lösung funktioniert nicht. Vielleicht dauert es einfach immer ein paar Stunden...
 
Ich habe ein ähnliches Problem, allerdings mit der 7490 und erst seit dem Update auf 7.26/7.27.

Bei FW 7.21 war der Speicher per SMB v2/v3 angebunden und über Windows uneingeschränkt erreichbar. SMB v1 war in der Box und Windows deaktiviert.
Nach dem Update auf FW V7.27 komme ich per SMB nicht mehr auf das NAS, egal welche Plattform (Linux/Win/Android). Downgrade auf 7.21 und alles ist wieder super....

Nach einiger Forschung:
SMB v2/3 auf ein Synology NAS funktioniert, also kein SMB/Win/Netzwerkproblem. Dafür spricht auch die Funktion nach dem Downgrade der Box.
Ping auf die Box und Zugriff per FTP funktioniert.
Deaktivieren/Aktivieren des Speichers bringt auch nach 1 Tag nichts. Nutzer neu anlegen etc. auch nichts.

Schau mal unter Diagnose - Sicherheit - "Heimnetz - FRITZ!Box-Dienste", ob die Ports 137-139 & 445 geöffnet sind.
Bei mir sind sie das bei FW 7.21 korrekt, ab FW7.26 jedoch NICHT mehr.... Daher auch kein Zugriff via SMB clients und nur die lapidare Meldung "Netzwerkpfad nicht gefunden ".
Auch ein externer Portscan der Box zeigte dieses Bild.

AVM ist dran, aber bisher keinerlei Lösungsansatz der erfolgversprechend wäre.
Ich habe schon Tage nach ähnlichen Fällen gesucht, aber bisher nichts dazu gefunden. Ich kann nicht mal sagen, dass das bei mir nur ein Einzelfall ist oder ein FW-Bug.
Allerdings habe ich mit 7.26/7.27 SMB noch gar nicht zum Laufen gebracht.... über ein kurzes Zucken würde ich mich schon freuen :)
 
  • Like
Reaktionen: gimnasia
Schau mal unter Diagnose - Sicherheit - "Heimnetz - FRITZ!Box-Dienste", ob die Ports 137-139 & 445 geöffnet sind.
Sind sie in der Tat nicht... Ich nutze zwar zwischenzeitlich FTP als Workaround, da sind aber die Zeitstempel der Dateien... ungenau (irgendwie so--- müsste ich jetzt nochmal nachgucken).

"AVM ist dran" - wo? Hast Du einen Link dafür?
 
Damit meinte ich, AVM bearbeitet ein Ticket von mir mit genau diesem Problem und dem Hinweis in welche Richtung es gehen könnte.
Allerdings kommen Sie mit den Diagnosedaten der Box nicht so recht weiter. Irgendwo klar, keine Ports offen, dann wird auch keine Anfrage etc. geloggt.

Ich habe das Gefühl, Sie können das Problem nicht nachstellen, nachvollziehen oder reproduzieren. Scheinbar läuft auf ihren Boxen der SMB.... Daher ist das vermutlich etwas stochern im Nebel.
Lediglich im Diagnosefile habe ich einen Hinweis gefunden:
Code:
aura state
----------
Error: AURA Daemon not accessible!
aura:settings/  or  aura:status/
enabled=0
aura4storage=0
aura4printer=0
aura4other=0
status=1
##### END SECTION usb_support
##### END SECTION devices
##### BEGIN SECTION filesystems Filesystems
##### BEGIN SECTION smb Samba
cat: can't open '/var/tmp/samba/lib/smb.conf': No such file or directory
##### END SECTION smb
##### BEGIN SECTION avmdb Log avmdb

AURA ist die "AVM USB Remote-Architecture". Also der USB-Fernzugriff, welcher bei mir auch deaktiviert wäre, ergo korrekte Meldung.
Allerdings fällt danach die SMB Zeile ins Auge, was auch für das fehlende SMB eine Erklärung wäre.
Der USB Stick läuft, Webinterface und FTP funktionieren. Keine Ahnung, ob es damit zu tun hat oder an der fehlenden/falschen smb.conf hakt...
 
Da hast Du Dich aufs Glatteis locken lassen - aktuelle Versionen haben keine smb.conf mehr, weil sie auch kein Samba benutzen. Dieser Versuch, die Datei in die Support-Daten aufzunehmen, stammt noch aus alten Versionen - von solchen Artefakten gibt es noch viel mehr in den Skript-Files für die Support-Daten.

Der aktuell verwendete nqcs (und auch der wssd wohl hinsichtlich des Namens der "Arbeitsgruppe") werden über die Datei [/var]/tmp/nq/config konfiguriert. Wenn Du Informationen zum Status des nqcs suchst, mußt Du schon in die Sektion ##### BEGIN SECTION nqcs_log schauen.
 
Danke für die Aufklärung.
Ich bin nur Endnutzer der Box und würde gerne wieder via Samba von einem Endgerät auf die NAS Freigaben zugreifen.
Ich sehe mich da technisch nicht im Stande oder der zeitlichen Verfügung für AVM diese Bugs als Developer zu debuggen.
Im Rahmen von eigenen Firmware-Files und "rooting" mag der ein oder andere da tiefere Einblicke haben und ggf. eine heiße Spur an AVM melden.
Ich will einfach eine SMB Freigabe auch per SMB erreichen können. Und das geht aktuell mit den dazu fehlenden Ports nur schwerlich.

...weil sie auch kein Samba benutzen.
Aber genau das will ich ja haben. Samba Zugriff.... Heißt das, dass ggf. auch die typischen SMB Ports nicht mehr benutzt werden?
Einen Eintrag ##### BEGIN SECTION nqcs.log gibt es in meiner Diagnosedatei leider gar nicht.
 
gibt es in meiner Diagnosedatei leider gar nicht
Ja, da habe ich mich wohl genauso locken lassen - denn die Ausgabe dieses Abschnitts ist von der Existenz der Log-Datei abhängig:
Code:
if [ -f /tmp/nq/log ]; then
echo "##### BEGIN SECTION nqcs_log"
cat /tmp/nq/log
echo "##### END SECTION nqcs_log"
fi
und wenn der fehlt, gibt es offenbar die Protokoll-Datei nicht.

Obendrein sieht es (ich habe eben gerade noch einmal nachgesehen) auch so aus, als würde die standardmäßig gar nicht erstellt - es macht sogar den Eindruck, als enthielte das Binary (in der 07.27-88306) gar keine Protokollierung (zumindest keine ausführliche), weil es (fast) keine passenden Meldungen in der (ausführbaren) Datei gibt und es sieht auch nichts nach einer passenden Einstellung in der config aus, mit der man ein Protokoll aktivieren könnte.



Aber es gibt schon noch einen Unterschied zwischen "kein Samba" und "kein Samba-Zugriff" - das macht AVM mittlerweile (irgendwann seit 07.xx) mit einer Dritt-Software (ebendiesem nqcs) und daher wirst Du - auch dann, wenn das Problem von AVM gefunden wird - immer noch kein Samba auf der Box haben, was aber einen Samba-Zugriff nicht ausschließt.

Und zur Frage der Ports ... die sind naturgemäß auch nur dann "offen", wenn wenigstens der Daemon dahinter läuft - ansonsten ist es doch ganz logisch, daß die "zu" sind. Ob der Prozess für den nqcs läuft oder nicht, steht auch gleich am Beginn der Support-Datei (da sind mehrere ps-Ausgaben enthalten) ... fehlt der Prozess, KANN gar kein Samba-Zugriff funktionieren (wobei hier dann tatsächlich SMB wieder besser paßt).



Ich würde (auch wenn ich nicht AVM bin) hier ja mal einen Blick in die Einstellungen werfen (speziell in die usb.cfg, die sich in der Sicherung finden läßt) - gerade dann, wenn ich den Eindruck hätte, daß AVM das nicht allzu hoch priorisiert, weil es sich um einen Ausnahmefall handelt (und so viele Berichte in diese Richtung gibt es selbst hier eben nicht).

Da der nqcs eben KEIN Samba-Server ist, reicht - wenn es schlecht läuft - schon irgendeine (alte) Einstellung aus, damit der nqcs abstürzt bzw. gar nicht erst startet, denn eine seiner ersten Aktionen ist es eigentlich, einen eigenen Prozess zur "Überwachung" seiner Aktivitäten zu forken (als crashwatcher), der ihn nach Abstürzen wiederbelebt.

Wobei das die Frage, warum es erst jetzt auftritt, auch noch nicht abschließend beantworten würde (denn auch die 07.21 verwendet schon den nqcs) - aber vielleicht ist es tatsächlich so simpel, daß in der usb.cfg etwas anderes steht, als im GUI angezeigt wird. Die usb.cfg enthält auch keine geheimen Daten (und wenn, sind sie so verschlüsselt, daß außerhalb der Box damit nichts anzufangen ist in aller Regel) und kann daher auch hier in voller Schönheit gezeigt werden, wenn Du sie nicht selbst interpretieren kannst. Kurz vor den AURA-Settings, die Du oben ja schon gefunden hattest, steht auch die gesamte Ausgabe von ctlusb - darin sind auch die kompletten Samba-Einstellungen enthalten ... das wäre eine Alternative (bzw. sogar eine Ergänzung) zum Inhalt der usb.cfg, weil letzterer den "gespeicherten" Zustand abbildet und der ctlusb-Part den, der sich nach dem Laden der Einstellungen ergeben hat.
 
Danke für die ausführliche Antwort.
Ich versuche mich mal durch zu wühlen:

In der Diagnosedatei steht nur 1x was mit nqcs im Bereich ##### BEGIN SECTION dmesg
[ 31.680000] type=1400 audit(31.680:2): apparmor="STATUS" operation="profile_load" name="/sbin/nqcs" pid=2222 comm="dd"
Ansonsten nicht existent.

Auf das Problem mit den Ports bin ich auch gestoßen. Keiner offen, keine Funktion. Da ich die identische Config von der 7.21 auch in der 7.26/7.27 nutze, sehe ich da das Problem liegen. AVM hätte aber gerne, dass ich die FAQ Punkt für Punkt abarbeite.... Und das zieht sich mit jeder Antwort etwas.

Der "samba-server-string" ist in den Dateien ersetzt. Da steht normalerweise mein Name. UTF8 kompatibel :)

usb.cfg:
Code:
/*
* /var/tmp.cfg
* Fri May 28 17:45:57 2021
*/

meta { encoding = "utf-8"; }

usbhost {
        readonly = no;
        password = "";
        autoprov_enabled = no;
        ftp_internet_enabled = no;
        aura_enabled = no;
        aura_config = 0;
        ftp_server_enabled = yes;
        samba_server_enabled = yes;
        samba_server_workgroup = "WORKGROUP";
        samba_server_server_string = "XXX:-)";
        users_enabled = yes;
        acl_directories {
                path = "/";
                access {
                        UserID = 10;
                        local_read = yes;
                        local_write = yes;
                        internet_read = no;
                        internet_write = no;
                }
        } {
                path = "/SanDisk-UltraUSB3-0-01/Kamera";
                access {
                        UserID = 11;
                        local_read = yes;
                        local_write = yes;
                        internet_read = no;
                        internet_write = no;
                }
        }
        spindown_enabled = yes;
        spindown_time = 0;
        usbhost_version = 4;
        internet_secured_only = no;
        fritznas_share = "NAS";
        usb3port_config = 1;
        volume_labels = no;
        ftp_internet_port = 44697;
        nas_enabled = yes;
        samba_server_smbv1_enabled = no;
        fritznas_always_index = yes;
}


webdavclient {
        enabled = no;
        host_url = "https://sd2dav.1und1.de";
        username = "";
        password = "";
        mountpoint = "Online-Speicher";
        cache_files = 2000;
}


media {
        media_server_enabled = no;
        homedir = "";
        media_server_name = "Mediaserver";
}


t_media {
        enabled = no;
        oauthstate = eauth_state_service_unused;
        refreshtoken = "";
        accesstoken = "";
        atok_expire = "1970-01-01 00:00:00";
        refresh_done = no;
        tcom_hidrive_rtok = "";
        tcom_hidrive_atok = "";
        tcom_hidrive_atok_expire = "1970-01-01 00:00:00";
        strato_hidrive_atok = "";
        strato_hidrive_atok_expire = "1970-01-01 00:00:00";
}


internalflash {
        enabled = no;
        mountpoint = "Interner Speicher";
        converted = no;
}


nasdb {
        nasdb_autostart = no;
        nasdb_autoindex = no;
}


// EOF

ctlusb:
Code:
##### BEGIN SECTION usb_support Supportdata USB
---
ctlusb:settings/  or  ctlusb:status/
device=SanDisk, Ultra USB 3.0
hubcount=0
power_rejected=0
printer-avail=0
printer-status=4
storage-ftp-internet=0
ftp-server-enabled=1
samba-server-enabled=1
samba-server-smbv1-enabled=0
unplug=0
unplug-status=0
unplug-ok=0
storage_spindown=1
storage_spindown_time=0
storage_spindown_test=0
internalflash_enabled=1
internet-secured=0
fritznas_share=NAS
samba-workgroup=WORKGROUP
samba-server-string=XXX:-)
storage-ftp-internet-port=44697
storage-ftp-internet-with-random-port=0
nas-enabled=1
storage-ftp-internet-on-demand-only=0
fritznas-always-index=1
autoprov_enabled=0
usb3port_config=1
usb3port_switchable=3
port_count=2
---
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SanDisk  Model: Ultra USB 3.0    Rev: 1.00
  Type:   Direct-Access                    ANSI  SCSI revision: 06
   Host scsi0: usb-storage
       Vendor: SanDisk
      Product: Ultra USB 3.0
Serial Number: 4C530001270701119543
     Protocol: Transparent SCSI
    Transport: Bulk
       Quirks: SANE_SENSE
/dev/sda1: LABEL="USB" UUID="50CE5EC1CE5E9ED2" TYPE="ntfs"
/dev/sda: PTTYPE="dos"
/dev/sda1: LABEL="USB" UUID="50CE5EC1CE5E9ED2" TYPE="ntfs" USAGE="filesystem" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0x7" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="32" PART_ENTRY_SIZE="240254944" PART_ENTRY_DISK="8:0"
---
/sys/bus/usb/devices/2-1/bConfigurationValue:1
/sys/bus/usb/devices/usb1/bConfigurationValue:1
/sys/bus/usb/devices/usb2/bConfigurationValue:1
---
/sys/module/usbcore/parameters/authorized_default:-1
/sys/module/usbcore/parameters/enum_error_count:0
/sys/module/usbcore/parameters/initial_descriptor_timeout:5000
/sys/module/usbcore/parameters/overcurrent_error_count:0
/sys/module/usbcore/parameters/reconnect_count:0
/sys/module/usbcore/parameters/reset_resume_count:0
/sys/module/usbcore/parameters/resume_error_count:0
/sys/module/usbcore/parameters/suspend_blacklist_size:0
/sys/module/usbcore/parameters/suspend_count:3
/sys/module/usbcore/parameters/suspend_error_count:0
/sys/module/usbcore/parameters/usbfs_memory_mb:16
/sys/module/usb_storage/parameters/bytes_transferred:8287516
/sys/module/usb_storage/parameters/delay_use:5
/sys/module/usb_storage/parameters/gb_transferred:0
/sys/module/usb_storage/parameters/max_spinup_ms:100
/sys/module/usb_storage/parameters/option_zero_cd:1
/sys/module/usb_storage/parameters/reset_count:0
/sys/module/usb_storage/parameters/spinup_error_count:0
/sys/module/usb_storage/parameters/swi_tru_install:1
---
/sys/block/sda/device/max_spinup_ms:100
---
/sys/bus/usb/devices/2-1/avm_usb_suspend_delay:20
/sys/bus/usb/devices/2-1/avm_usb_suspend_enable:1
/sys/bus/usb/devices/2-1/avm_usb_suspend_status:active
/sys/bus/usb/devices/usb1/avm_usb_suspend_delay:60
/sys/bus/usb/devices/usb1/avm_usb_suspend_enable:0
/sys/bus/usb/devices/usb1/avm_usb_suspend_status:active
/sys/bus/usb/devices/usb2/avm_usb_suspend_delay:60
/sys/bus/usb/devices/usb2/avm_usb_suspend_enable:0
/sys/bus/usb/devices/usb2/avm_usb_suspend_status:active
---

Wie gesagt, der Speicher (intern & USB) funktionieren. Zugriff aber eben nur per Webinterface oder FTP.

In der usb.cfg steht "samba_server_server_string" und in der Diagnose lediglich "samba_server_string". Sieht für mich eigenartig aus.
 
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.
 
Das Problem mit den Ports habe ich nur versucht zu erklären - das ist ZU ERWARTEN, wenn da der Server-Prozess nicht läuft.
Das sehe ich genauso. Nur AVM möchte das laut den Ticket-Lösungsvorschlägen (in meinen Augen) noch nicht so sehen. Trotz diverser Hinweise auf die Ports. Aber abwarten.

Der Name wäre ASCII konform ohne ä,ö,ü und ?. 0815 deutscher Nachnahme. Muss aber nicht unbedingt ins Forum, daher der Hinweis, dass ich den im Code ersetzt habe.
Ich lese mich mal Stück für Stück durch deinen Input und versuche das einzugrenzen. Sofern ich es mit meinem Wissensstand umsetzen kann. Da besteht noch etwas "Unwissenheit", aber nichts was man sich nicht aneignen könnte.
Ich nutze meine Box mit der AVM GUI, keine eigenen Konfiguration oder Ähnliches. Hatte schon nachzulesen, wie ich die usb.cfg aus der Export heraus bekomme. Daher gehe ich davon aus, dass das
Code:
volume_labels = no
tatsächlich übernommen wurde.
Der Share Name "NAS" hat bisher funktioniert. Hatte zwischenzeitlich aber auch mal einen anderen Namen und den Standard "fritz.nas" ausprobiert.

Eine komplette Neueinrichtung wollte ich aus Bequemlichkeit vermeiden. Scheint aber mittlerweile ne valide Option zu sein.
Ja, die Config ist mindestens seit V6.23 bestehend, da dies das erste FW-file ist, welches ich im Backup gefunden habe. Bei mir handelt es sich jedoch um eine 7490.
Allerdings sagt AVM wiederum auch nicht, dass man die Config nicht mitnehmen kann/soll.... Warum sollte ich also als Otto-Normal-User die Box nach einen Update neu aufsetzten?

Ich werde das Pferd vermutlich rückwärts aufzäumen.
Box recht simpel neu einrichten (nur internes NAS und Benutzer dazu) und sehen ob das out-of-the-box funktioniert.
Falls das läuft, werde ich mal das Backup einspielen und weiter in der Tiefe suchen.

Ich habe das Thema der 7590 mittlerweile quasi gekapert, weil das laut Internetrecherche am ehestem meinem Problem entsprochen hat und dieses Forum eine gewisse technische Tiefe vorweist.
Ich hoffe, eine entsprechende Lösung lässt sich trotzdem für die 7590 nutzen und kommt somit letztendlich auch dem Themenersteller zugute.

Danke für den fundierten Einblick in die Box!
 
Ich werde das Pferd vermutlich rückwärts aufzäumen.
Box recht simpel neu einrichten (nur internes NAS und Benutzer dazu) und sehen ob das out-of-the-box funktioniert.
Falls das läuft, werde ich mal das Backup einspielen und weiter in der Tiefe suchen.
Zwischenruf: Ich verfolge das hier, aber habe einfach keine Zeit mehr in die Tiefe zu gehen. Geschweige denn, die ganze Box von vorne neu zu konfigurieren. Meine Konfig dürfte mit der 7490 neu entstanden sein, habe sie dann für die 7590 übernommen.
Vielen Dank für Eure Mühe.
 
Kurze Rückmeldung:
scheint definitiv ein Problem mit dem nqcs zu sein, der mit FW7.27 einfach nicht (mehr) startet. Habe in 2 Wochen etwas mehr Zeit und werde mal die 7.21 aufspielen und deren Logs ansehen, ob da mehr drin steht (wenn der nqcs läuft).

AVM kann man vermutlich vergessen:
"In den vorliegenden Support-Daten konnten wir das Verhalten nicht eingrenzen und auch nicht erfolgreich reproduzieren.
...
Starten Sie die Mitschnitte bitte, bevor der Zugriff scheitert und beenden Sie sie erst, nachdem Sie das Verhalten vollständig reproduziert haben."

Mittschnitte der Fritte :-D Dabei macht die Box ja nicht mal die Ports auf, was soll da mitgeschnitten werden?!....
Das ist mir irgendwie zu doof, mich da weiter mit dem Support in dem Problem zu vertiefen.
 
Logs ansehen, ob da mehr drin steht (wenn der nqcs läuft).
Tu, was Du nicht lassen kannst - ich wäre aber sehr verblüfft, wenn da tatsächlich etwas protokolliert würde (siehe meine Korrektur der anfänglichen Meinung in #13), denn in der Datei des Daemons sind gar keine passenden Vorkehrungen dafür zu finden. Auch nicht in der 07.21 - die Dateien unterscheiden sich nämlich nur marginal ... die in der 07.21 ist 120 Byte größer, da passen nicht sooo viele zusätzliche Nachrichten in die Datei.

Warum versuchst Du nicht erst einmal, auf dem oben vorgeschlagenen Weg zu ermitteln, ob das AVM-Programm tatsächlich eine gültige Konfigurationsdatei erstellt? Wenn das nicht der Fall ist, wird der nqcs ohnehin nicht starten. Und wenn das AVM-Programm tatsächlich als "Übeltäter" ausgemacht sein sollte, dann kann man das auch mal "von Hand" in einer Shell aufrufen (in einer 7490 ist die ja nun im Handumdrehen eingerichtet) ... da sind dann tatsächlich ein paar potentielle Fehlermeldungen zu sehen, wenn man die Zeichenketten in DIESEM Programm näher unter die Lupe nimmt.

Letztlich läuft es wohl auf die Frage hinaus, ob Du tatsächlich ermitteln willst, wo das Problem liegt und worum es sich dabei handelt oder ob Du das nur "weg haben" willst - DAS wirst Du vermutlich mit weiteren Wechseln des OS (womit dann ja auch weitere Restore-Aktionen für die Konfiguration verbunden sind, wenn es ein Downgrade ist) tatsächlich erreichen können (auch wenn das vermutlich schon mit einer echten Neukonfiguration erledigt wäre - aber die wolltest Du vor einiger Zeit (#16) ja eigentlich noch vermeiden).

Ein Import einer alten Konfiguration ist bei AVM nun einmal etwas anderes, als ein Update des OS und damit einhergehende Änderungen an den bereits vorhandenen Konfigurationsdateien. Beim Import wird mehr "weggeworfen" (bzw. kann mehr ausgelassen werden), als beim (einmaligen) Konvertieren einer bereits existierenden Konfiguration - es gibt nun mal vieles in den AVM-Einstellungen, was voneinander abhängig ist (nur mal VPN-Konfiguration und Benutzerkonten als Beispiel genannt).

Die Annahme, man könne mit dem Wiederherstellen zuvor gesicherter Einstellungen tatsächlich 1:1 den alten Zustand reproduzieren, ist eine reine Milchmädchenrechnung (und funktioniert bei AVM bekannterweise nicht - eigentlich noch nie und die eingeführte "Bulk"-Option beim Wiederherstellen von DECT-Pairings ist da auch nur eine "Erleichterung", die lange genug gebraucht hat, bis sie implementiert war) ... das mit 1:1 gilt höchstens dann, wenn man diesen Import auch zuvor schon ausgeführt hatte und es sich damit letztlich nur um eine Wiederholung handelt - aber auch das wieder nur dann, wenn man dabei genauso vorgeht, wie beim ersten Mal (und ohne Gedanken an das Pairing der DECT-Devices).

Es ist nun einmal auch (nachweislich) Fakt, daß eine Sicherungsdatei bei AVM keineswegs alle Einstellungen enthält - wenn das Problem von einer der "nicht gesicherten" herrühren sollte (bzw. von einer nicht wiederhergestellten, denn auch da findet - sogar neben der angebotenen Liste bei selektiver Übernahme - noch eine Filterung statt), KANN man das nachträglich vermutlich auch nicht mehr reproduzieren und ich glaube AVM schon, daß man dort Probleme hat, diesen Fehler nachzustellen ... auch wenn der Support dann falsch weitersuchen will - das erscheint auch mir eher Hilflosigkeit und Aktionismus, damit man nicht nur mit den Schultern zucken muß.

Es ist am Ende Deine Entscheidung, was Dir jetzt wichtiger ist ... eine irgendwie funktionierende Box mit SMB-Zugriff oder die Suche nach der Ursache eines - offenbar sehr seltenen - Problems. Dem AVM-Support wird's egal sein ... aber wenn Du die Ursache finden willst, riskierst Du mit jedem Downgrade und mit jedem Import von Einstellungen, daß die fehlerverursachende Konstellation "beschädigt" wird und Du am Ende halt eine funktionierende Box hast, aber hinsichtlich der Ursache des Problems weiterhin nur das große Schulterzucken bleibt.
 
So, danke für die vielen Hinweise und Ansätze. Allerdings bin ich als Endnutzer mit der Tiefe deiner Ausführung an meine IT-Grenzen gestoßen....

Aber:
Ich habe mich trotzdem hingesetzt, die 7490 auf Werkseinstellung gesetzt und Stück für Stück angefangen neu zu konfigurieren.
Zuerst mal nur ein Gerät mit WLAN Zugriff und direkt danach das interne BoxNas mit einem Benutzer. Lief einwandfrei. Ports 137-139 & 445 sieht man nun auch in der Diagnose als geöffnet.
Also Step by Step weiter konfiguriert. USB Stick => i.O. LAN, WLAN, DECT usw. i.O.
Alles super bis kurz vor Ende:
Zu aller Letzt habe ich nun wieder meinen 2ten Benutzer mit Zugriff auf das NAS angelegt. Lediglich für Netzwerkkameras, welche per FTP auf den Stick Snapshots packen.
Und voila, kein Zugriff mehr. 2ten Benutzer gelöscht => Zugriff wieder da.
Weil es schon egal war, testweise alte Sicherung eingespielt, 2ten Benutzer gelöscht => Zugriff aufs NAS via SMB2/3 wieder möglich.

Das könnte auch zur ursprünglichen Problembeschreibung passen:

Nun, die Box lebt, anpingen kann man sie, die SMB-User sind weiterhin konfiguriert wie immer... aber via SMB kommt kein Gerät mehr dran. Egal welcher der eingerichteten SMB-User genutzt wird. Das Komische: auch nach einem Neustart der Fritzbox nicht mehr.

Übrigens gerade jetzt auch nach Firmware-Update und Neustart - keine Chance mit SMB. Auch die Endgeräte kann ich neu starten, es bringt dann nichts.
Auch habe ich mal den Zugriff auf NAS-Inhalte dem SMB-User entfernt, gespeichert, dann wieder hinzugefügt. So dass sozusagen die Karten mit SMB neu gemischt werden. Bringt aber nichts. Kein Connect.

Nun habe ich weiter gespielt. Es gibt scheinbar einen Zusammenhang zwischen "FritzBox Name" und "USB Speicher Heimnetz Name". Sobald man den Namen der Box ändert (ohne die WLAN SSIDs mit zu ändern), wird automatisch der NAS Freigabename mit geändert.
Dabei gilt: FritzBox Name = NAS Freigabename. Sobald ich nun nachträglich den NAS Freigabenamen wieder abändere, sind die Ports wieder tot, bis ich den FritzBox-Namen erneut anpasse und die NAS Freigabe identisch übernommen wird.

Heißt:
Es gibt scheinbar diffuse Probleme beim starten des nqcs bedingt durch multiple Benutzer oder abweichende Namen zwischen Box und Freigabe.
Eine genaue Reihenfolge habe ich noch nicht nachstellen können. Letztendlich habe ich nun unterschiedliche Namen der Box sowie Freigabe und 1 Benutzer oder gleiche Namen und mehr als 1 Benutzer hinbekommen..... Die Funktion scheint aber etwas vom Glück abhängig zu sein.
Wirklich zuverlässig läuft lediglich Box Name = Freigabename & 1 Benutzer
Darüber hinaus scheint Box Name = Freigabename & mehrere Benutzer erst stabil zu starten, wenn nach dem Anlegen aller Benutzer der Box und Freigabename erneut geändert wird (oder doppelt (wieder zurück zum alten Namen)).
Sobald man an einem Benutzer etwas ändert und übernimmt, beginnt das Spiel von vorne. Ports zu, Box Name ändern, Ports werden wieder geöffnet....

Sobald man jedoch Box Name ungleich Freigabename eingibt, funktioniert es mit mehreren Benutzern definitiv nicht mehr. Auch ein nachträgliches "zurück ändern" der Freigabe bringt nichts. Es muss scheinbar tatsächlich über den Dialog des FritzBox Namens erfolgen.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.