Windows 10 - 1709 hat Probleme mit Zugriff auf Synology

[NSFH]

Der Linux Server (Ubuntu aktuelle LTS) läuft genau wie von dir beschrieben mit identischen Nutzernamen und Kennwörtern.
Evtl spielt dann doch die unter Win bekannte Guest Problematik irgendwie eine Rolle, das da in der Syno bei Abfrage der ACL irgendwas schief läuft. Das wäre dann ein Rechteprobleme und nicht ursächlich ein Protokollproblem.
Bin da auch vollkommen überfragt, kann es im Moment aber auch nicht testen, da im Netz der RS815 noch alle 10 Clients ohne Creator laufen.

 

[Yippie]

Hier nochmals mein Senf dazu: Ich habe SMB1 auf einem Windows Client aktiviert, nur den Client Teil, greife fast ausschließlich mit einer IP álà \\192.168.6.97\<share> auf die Synology Freigaben zu und habe damit keinerlei Probleme (mehr). Wie von mir bereits weiter oben erwähnt, habe ich auf meinen beiden Synologys als min Protokoll SMB2 und als max. SMB3 eingestellt.

MTU-Wert, sollte ich vielleicht noch erwähnen, weil dies im Zusammenhang mit dem ebenfalls installiertem Active Directory Server (auf der DS916+) bei mir eine große Rolle gespielt hat, ist auf Standard gestellt, also 1500. Apropos AD-Server. Meine NAS-Freigaben sind ausschließlich über Domänen-Gruppen berechtigt, ich nutze also keinen lokalen DSM-Benutzer mehr. Alle meine Windows Geräte befinden sich in der Windows-Domäne und melden sich ausschließlich per AD-Benutzer an.

Trotzdem hatte ich zunächst auch das Problem, mit der ersten auf 1709 upgedaten Win10 Pro Maschine, jedoch nur solange bis ich SMB1 (via Group-Policies) wieder aktiviert hatte.

Ich habe auf der besagten Maschine schon mehrere Reboots hinter mir genauso wir mehrere Stunden Arbeit, ohne dass es Probleme gab mit den Freigaben bzw. mit dem Zugriff auf das jeweilige NAS. Seither gab es auch noch kein Update seitens Synology...

Grüße,
Michael

 

[al3x82]

Laut diesem Thread hier bei Technet konnte Synology das Problem in einem Support-Ticket bei jemandem nachstellen:
https://social.technet.microsoft.com/Forums/en-US/f8cdb6d8-fae0-4661-ac1e-448ccbbafdd3/the-directory-name-is-invalid-when-opening-some-files-on-a-mounted-drive-to-my-synology-nas-after?forum=win10itpronetworking

Ich denke also, da wird es sehr bald einen Bugfix geben

 

[Erebus]

Ich denke also, da wird es sehr bald einen Bugfix geben

Hoffe ich doch.
Der bug ist nervig.

 

[NSFH]

Good news!
Wenn dieser Fehler im Firmen Nw auftritt habe ich ein massives Problem. Hoffe der Fix kommt bald!

 

[wech]

Ich habe den Fehler auch seit Update auf 1709 und habe mir aus Neugierde mal den Unterschied zwischen aktivem und deaktiviertem smb v1 client mal mit Wireshark genauer angeschaut.

Ohne aktives Laufwerksmapping sieht es so aus, dass ich bei deaktiviertem smb v1 eine Datei einmalig kopieren bzw. grundsätzlich esen kann, beim zweiten Versuch kommt die Fehlermeldung. Wenn man danach geschätzte 10-20 Sekunden wartet, kommt eine smb Tree Disconnect Message und danach kann die Datei wieder gelesen werden.

Interessant fand ich dabei, dass beim fehlgeschlagenen Folgeversuch keinerlei Anfragen an die Synology geschickt werden - Windows "weiß" vorher schon dass es nicht klappt - oder meint das zumindest fälschlicherweise.

Wenig überraschend wird beim Negotiate Protocol Request mit aktivem smbV1 eine längere Liste von Dialekten gesendet, nämlich:
PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12, SMB 2.002, SMB 2.???,
während bei deaktiviertem nur folgende angeboten werden:
NT LM 0.12, SMB 2.002, SMB 2.???

Nicht wundern über das SMB 2.???. Das wird in einem zweiten Protokoll-Handshake dann genauer vereinbart, mit idemtischem Ergebnis, nämlich Dialect 0x0311

Danach fallen dann zwei Unterschiede auf: bei aktivem smbv1 wird als Antwort auf den Create-Request (um die Datei zum lesen zu öffnen), als QFid folgendes geliefert:
Opaque File ID: 84c54b020000000000fd0000000000000000000000000000...
bei deaktiviertem smbv1 dagegen
Opaque File ID: 000000000000000000fd0000000000000000000000000000...

Der zweite Unterschied und vermutlich eigentliche Fehler ist aber der nächste Find-Request, der dazu dient einen Verzeichnisinhalt aufzulisten:

[Info Level: SMB2_FIND_ID_BOTH_DIRECTORY_INFO (37)]

Als Ergebnis kommen alle Dateien des Verzeichnisses, inklusive "." und ".."
Der große Unterschied ist das Feld File Id. Bei aktivem smbv1 ist dort folgendes
".": 0x0000000000000f20
"..": 0x0000000000000002
"testdatei": 0x00000000024bc584

bei deaktiviertem smbv1
".": 0x0000000000000000
"..": 0x0000000000000000
"testdatei": 0x0000000000000000

Also alle File Id sind dann 0. Ich vermute, dass genau das dann windows dazu bewegt beim nächsten Versuch das Verzeichnis als ungültig zu betrachten.

Viel weiter hilfts natürlich jetzt niemandem, weil trotzdem Synology den Fehler beheben muss - vermutlich wird irgend etwas nicht vollständig initialisiert wenn beim Protokoll aushandeln eines der Protokolle fehlt - aber ich fand es trotzdem interessant, und vielleicht noch jemand anderes auch ;-)

Schöne Grüße
wech

 

[vater]

Willkommen im Forum!
Und der erste Post gleich sowas. Danke
Ich hoffe Synology liest da mit..
Viele Grüße
Vater

 

[Swiss-MAD]

aber ich fand es trotzdem interessant, und vielleicht noch jemand anderes auch ;-)

Ja auf alle Fälle interessant, ich mag solche Forschungen / Experimente
Selbst bin ich in Netzwerktechnik nicht so fit als das ich das Analysieren hätte können.

 

[vater]

Ich habe gestern vom Synology Support ein bebildertes Mini-How-to enable v1 SMB Client als Workaround bekommen. Ich hatte sie auf Wechs Tiefenanalyse in diesem Thread hingewiesen

 

[blinddark]

Kannst du diesen Workaround in Worte fassen? Welche Haken müssen gesetzt werden?

 

[vater]

Oh, der ist hier im Thread schon vorhanden. al3x82 hat ihn in auf Seite 2 Post #17 inkl. Screenshot beschreiben.

 

[ds211user]

Hallo zusammen,

ein ähnliches Problem, in meinem Fall sind es aber einzelne Dateien.
Zugriff von Windows aus geht nicht. Das ist bei W10 1703 der Fall.
Lade ich die betreffende Datei runter, ist sie intakt. Test auf dem selben Windows Client.

Bin ich damit hier richtig? Oder ist das was anderes?

Nachtrag:
Inzwischen funktioniert eine der Dateien wieder. Ohne Änderung.
Scheint also ein zeitlich begrenztes Phänomen zu sein.

Wahrscheinlich scheppert es dann irgend wann irgend wo anders.
Das Kopieren von einer DS auf die andere geht auch.
Die Dateien sind im Binärvergleich identisch.

 

[blinddark]

al3x82 hat ihn in auf Seite 2 Post #17 inkl. Screenshot beschreiben.

kann mir eventuell jemand sagen, welcher Haken im Post 17 gesetzt ist? Automatic removal oder client? Meine Texterkennung erkennt die haken nicht.

 

[Swiss-MAD]

Bei CIFS-Client ist der Haken.
Automatic Removal und CIFS-Server sind ohne

 

[vater]

Aber selbstverständlich: Im Baum Unterstützung für die SMB 1.0/CIFS-Dateifreigabe gibt es drei Optionen. Dort reicht die Option SMB 1.0/CIFS-Client. Viele Grüße, Vater
Edit: Swiss-MAD hatte schon geantwortet, sorry. Keine Ahnung, warum ich das eben übersehen hab.

 

[MOrtny]

Hallo Wech,

vielen Dank für die Analyse. Ich konnte genau dieses Verhalten bei uns auch nachvollziehen.

In einem anderen Synology Forum habe ich folgenden Lösungsansatz gefunden :

no need to enable SMB1 again. Stay on SMB2 at minimum and keep your system safe:

- go onto SMB/ Advanced settings (using smb2 / SMB3) Disable "transport encryption mode" . Probelm solved.

check when you can re-enable as soon fix has been released.

https://forum.synology.com/enu/viewtopic.php?f=49&t=136305#p505039

Vielleicht funktioniert das bei euch, und ihr könnt damit die Benutzung von SMB v1 deaktiviert lassen.

Bei uns tut es leider nicht, sodass uns bisher als Lösungsansatz nur die Aktivierung des SMB 1.0/CIFS-Client bleibt

Hoffe auf ein baldiges DSM Update !

 

[wech]

@MOrtny Bei mir hat das deaktivieren der Verschlüsselung auf synology-seite leider auch nicht geholfen. Als Mindestprotokoll auf Syno-Seite waren durchgehend SMB2 und Maximalprotokoll SMB3 eingestellt.

Nur wenn auf Windows-10-Client-Seite "smb v1 Client" in den optional features aktiviert ist, klappt der Zugriff wieder zuverlässig, sonst bleibt es bei besagtem Fehler, dass die gleiche Datei einmal kopiert werden kann, danach ein Fehler kommt und es erst nach einiger Zeit wieder funktioniert.

Da es nur der smb-client ist, kann ich aktuell damit leben, beim Server hätte ich mehr Bedenken ;-)

 

[Adama]

Ein - wenn auch bisher kurzer - Test mit der neuen Version 6.1.4 lässt vermuten, dass der Fehler behoben ist...
Ich hab' jedenfalls ohne SMB 1 keine Probleme mehr... (fingers crossed)

 

[wech]

Es sieht tatsächlich aus als sei der Fehler mit 6.1.4 jetzt behoben. Aktuell kann ich es auch mit deaktiviertem smb 1 client nicht mehr reproduzieren, auch wenn die Release-Notes nichts explizit zu diesem Fehler sagen.

Ich vermute es ist 14. "Fixed search results filters of File Station, AFP and SMB to ensure that users can only find files with read permissions in their search results." da der Fehler beim Find-Aufruf war, oder eventuell "16. Fixed a security vulnerability regarding Samba (CVE-2017-11103)."

Aber hauptsache ist, es läuft wieder.

Bei der Antwort auf den Find-Request kommt im SMB2_FIND_ID_BOTH_DIRECTORY_INFO-Teil bei "." und ".." usw auch wieder bei File Id ein anderer Wert als 0x0.

 

[toeoe]

Hallo zusammen!

Ich hatte das gleiche Problem mit dem Zugriff seit den Windows-Update.

Leider gibt es jetzt (nach dem Synology Update auf 6.1.4) ein neues Problem. Mit deaktiviertem SMB-1-Client kann weder Word noch PowerPoint (jeweils Professional Plus 2016, Version 1710 (Build 8625.2121 Klick-und-Los)) eine Datei auf die Synology-Box speichern. Es kommt zu einem Absturz mit folgender Fehlermeldung:


Erst eine erneute Aktivierung des SMB-1-Clients lässt Word und PowerPoint wieder ohne Absturz speichern.
Übrigens: Excel macht keine analogen Probleme.

Hat jemand ein ähnliches Verhalten?