TS-453 Pro: User mit Netzlaufwerkverbindung auf Samba Shares wird nach Shutdown von Windows Clients (W7; W10) nicht abgemeldet

  • Ich besitze ein TS-453 Pro; QTS 4.2.2. Build 20160901; SAMBA Versionen 2.1 (aber auch 1.0; 2,0; 3.0) und habe folgendes Problem:

    • Ein Windows User (mit identischem Passwort unter Windows und QTS) nutzt unter Windows 7 oder Windows 10 Netzlaufwerkverbindungen zu Samba Shares (also mit zugeordneten Laufwerksbuchstaben) auf dem NAS funktional völlig problemlos.
    • Nach dem regulären Herunterfahren des Windows Clients (durch den jeweiligen User) wird der User jedoch am NAS nicht abgemeldet (bleibt über Tage hinweg im Systemprotokoll der Online Benutzer sichtbar).
    • Bei erneuter Anmeldung desselben Users am selben Windows-Client wird eine weitere SAMBA Verbindung unter identischem Benutzernamen und identischer IP-Adresse (per DHCP von Firtz!Box vergeben) als weiter Online Benutzer im Systemprotokoll ausgewiesen. Dies wiederholt sich so oft, wie sich der Nutzer unter Windows neu anmeldet (z.B. nach Neustart des Windows-Clients).
    • Meldet sich der User jedoch vor dem Shutdown des Windows-Clients explizit ab und fährt erst danach den Windows-Clients herunter, wird die SAMBA Verbindung im NAS ordnungsgemäß gelöscht.

    Das geschilderte Verhalten tritt sowohl unter Windows 7 als auch unter Windows 10 aniversary mit aktuellen Patches auf.


    Angewandter Workaround:
    Ausschließliche Nutzung von Links auf Samaba Shares im Windows Dateiexplorer.


    Anmerkung:
    Das Verhalten tritt auf meinem 2. NAS (TS-419 P II; QTS 4.2.2. Build 20160901) nicht auf!!


    Hat jemand dieses Problem auch beobachtet und ggf. einen Lösungsvorschlag für mich?

  • Auf die Schnelle fällt mir nur ein diese mit einem Script zu lösen.


    Beim Starten im Login-Script mit

    Code
    net use <Laufwerksbuchstabe:> \\<Servername>\<Freigabename>


    Netzlaufwerk hinzufügen.


    Beim Herunterfahren mit dem Logout-Script mit

    Code
    net use <Laufwerksbuchstabe:> /delete


    wieder löschen.


    Möglicherweise reicht auch


    Code
    net use <Laufwerksbuchstabe:> \\<Servername>\<Freigabename> /persistent:no


    im Startscript. Die zuvor manuell eingerichteten Netzwerklaufwerke vorher trennen.


    Mal im Technet net use nachlesen. Gibt vielleicht noch elegantere Lösungen.

    Einmal editiert, zuletzt von Mavalok2 () aus folgendem Grund: Korrektur Befehl

  • Danke für Deine schnellen Lösungsvorschläge! Da ich nur die Home Versionen von Windows besitze, kann ich die Gruppenrichtlinien nicht bearbeiten und damit ohne Tricks keine Login- und/ oder Logout Scripts erstellen. Habe mir daher folgende Batchdateien erstellt:


    Connet.bat:
    net use <Laufwerksbuchstabe:> \\<Servername>\<Freigabename>
    ...


    Disconnect.bat:
    net use <Laufwerksbuchstabe:> /delete
    ...


    Dadurch werden die Samba-Shares in QTS ordentlich an- und abgemeldet. Scheint also so zu sein, als ob beim regulären Windows Shutdown kein reguläres Abmelden der Samba Shares erfolgt. Seltsam ist nur, dass das nur beim TS-453 Pro passiert, nicht jedoch am TS-419 PII ?(


    Kannst Du diesen Effekt mit Deinen beiden NAS (TS-809 Pro und TS-419 PII) nachvollziehen?

    2 Mal editiert, zuletzt von hajojue () aus folgendem Grund: Update

  • Auf meiner TS-809 und TS-419P II wird nur per Verknüpfung und nicht per Netzwerklaufwerk zugegriffen, jedoch bei einer TS-231+. Mit Windows 7 Pro x64 Clients als Netzwerklaufwerke, jedoch per GPO eingebunden > keine Probleme, wird sogar beim Standby-Modus getrennt.
    Werde mal ein Netzwerklaufwerk manuell auf die TS-419P II einbinden. Habe jedoch nur Win7Pro Clients zur Verfügung. Melde mich.


    Edit:
    Auch manuell eingebunden keine Probleme.

    Einmal editiert, zuletzt von Mavalok2 () aus folgendem Grund: Update

  • Danke für Deine Bemühungen und die Informationen! Ich habe zu dem Thema ein Ticket bei QNAP aufgemacht. Mal sehen was dabei herauskommt (ich werde berichten). Bis dahin kann ich mit dem von Dir beschriebenen Workaround leben.

  • Also beim Anmelden kannst Du Dir das Leben erleichtern indem Du Deine "Connect.bat" beim Autostart hinzufügst.
    Ich bin der Meinung, dass es auch bei der Windows Home-Variante ein Möglichkeit gibt Logout-Scripte abzuarbeiten, sehr wahrscheinlich mit einem Eintrag in der Registry. Ansonsten gibt es sicher auch Hilfstools.


    Würde zwar eher auf ein Windowsproblem denn ein QNAP tippen, bin aber gespannt was der QNAP-Support dazu meint.

  • QNAP verwies auf das kommende final Release 4.3.3. Ich kann jedoch seit heute vermelden, dass der oben geschilderte Fehler mit QTS 4.2.5 build 20170413 unter Windows 10 Version 1703 (Creators Update) nicht mehr auftritt. Problem ist also gelöst :)

  • Besten Dank für das Feedback.


    Die schönsten Problem sind die, die sich von selbst auflösen. :)
    Noch besser sind die Probleme, die gar nicht entstehen. :D

  • Damit hast Du wirklich den Nagel auf den Kopf getroffen