Windows 10 - 1709 hat Probleme mit Zugriff auf Synology

Status
Für weitere Antworten geschlossen.

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
3.979
Punkte für Reaktionen
516
Punkte
174
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

Benutzer
Mitglied seit
01. Feb 2011
Beiträge
573
Punkte für Reaktionen
31
Punkte
54
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

Benutzer
Mitglied seit
04. Aug 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
Zuletzt bearbeitet:

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
3.979
Punkte für Reaktionen
516
Punkte
174
Good news!
Wenn dieser Fehler im Firmen Nw auftritt habe ich ein massives Problem. Hoffe der Fix kommt bald!
 

wech

Benutzer
Mitglied seit
27. Okt 2017
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
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

Benutzer
Mitglied seit
14. Mrz 2014
Beiträge
447
Punkte für Reaktionen
80
Punkte
28
Willkommen im Forum!
Und der erste Post gleich sowas. Danke :)
Ich hoffe Synology liest da mit..
Viele Grüße
Vater
 

Swiss-MAD

Benutzer
Mitglied seit
21. Apr 2016
Beiträge
97
Punkte für Reaktionen
1
Punkte
8
aber ich fand es trotzdem interessant, und vielleicht noch jemand anderes auch ;-)

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

vater

Benutzer
Mitglied seit
14. Mrz 2014
Beiträge
447
Punkte für Reaktionen
80
Punkte
28
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 :)
 
Zuletzt bearbeitet:

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.385
Punkte für Reaktionen
34
Punkte
68
Kannst du diesen Workaround in Worte fassen? Welche Haken müssen gesetzt werden?
 

vater

Benutzer
Mitglied seit
14. Mrz 2014
Beiträge
447
Punkte für Reaktionen
80
Punkte
28
Oh, der ist hier im Thread schon vorhanden. al3x82 hat ihn in auf Seite 2 Post #17 inkl. Screenshot beschreiben. :)
 

ds211user

Benutzer
Mitglied seit
27. Sep 2011
Beiträge
160
Punkte für Reaktionen
17
Punkte
18
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.
 
Zuletzt bearbeitet:

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.385
Punkte für Reaktionen
34
Punkte
68
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

Benutzer
Mitglied seit
21. Apr 2016
Beiträge
97
Punkte für Reaktionen
1
Punkte
8
Bei CIFS-Client ist der Haken.
Automatic Removal und CIFS-Server sind ohne
 

vater

Benutzer
Mitglied seit
14. Mrz 2014
Beiträge
447
Punkte für Reaktionen
80
Punkte
28
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.
 
Zuletzt bearbeitet:

MOrtny

Benutzer
Mitglied seit
15. Aug 2011
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
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. :confused:

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

Benutzer
Mitglied seit
27. Okt 2017
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
@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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
05. Mrz 2013
Beiträge
1.948
Punkte für Reaktionen
556
Punkte
134
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

Benutzer
Mitglied seit
27. Okt 2017
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
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

Benutzer
Mitglied seit
24. Feb 2013
Beiträge
19
Punkte für Reaktionen
0
Punkte
1
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:
word-fehler.PNG

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?
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat