Windows 10 - 1709 hat Probleme mit Zugriff auf Synology

[blinddark]

Danke für die ausführliche Rückmeldung.
Ich habe mir das Thema grade nochmal angesehen und mich hiernach gerichtet -> KLICK

Wie hast du die Abfrage ausgeführt? "Set-SmbServerConfiguration --AuditSmb1Sccess $True" Über Powershell?

 

[Adama]

Ich hab' gerade getestet, was ich gefunden hatte. Wie ich schon fast erwartet hab', hat das mit unserem Problem nichts zu tun.

 

[mondfee]

Ich habe eine DS415+ als Speicher










Seit dem Update auf Windows 10 1709 kann ich nicht mehr auf meine DS 415+ zugreifen. Ich habe versucht die DS mit Hilfe des Synology Assistant wieder einzurichten. Leider ohne Erfolg. Fehlermeldung lautet Verbindung fehlgeschlagen. Am unteren Rand allerdings der Hinweis 1 Synology Server gefunden. Ich habe auch schon versucht über Windows die DS im Netzwerk einzurichten, gleichfalls ohne Erfolg. Ich bin ratlos......hat jemand eine Idee. Noch ein Hinweis. Ich habe keine Ahnung von Programmen und Technik, also bitte habt verständniss wenn meine Fragen einfach klingen. Ich bin aboluter Laie. Danke!

 

[AndiHeitzer]

Wie hast du die Abfrage ausgeführt?

Ja, über Powershell.

Zuerst mit SmbServerConfiguration die Einstellungen ausgeben lassen:

PS C:\> SmbServerConfiguration




AnnounceComment                 :
AnnounceServer                  : False
AsynchronousCredits             : 64
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 15
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : True
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : False
EnableSMB1Protocol              : False
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                :
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : False
ServerHidden                    : True
Smb2CreditsMax                  : 2048
Smb2CreditsMin                  : 128
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

Sollte der Parameter EnableSMB1Protocol TRUE sein, so lässt er sich mit "Set-SmbServerConfiguration -EnableSMB1Protocol $FALSE" abschalten.

Die Powershell muß für Korrekturen im ADMIN-Mode ausgeführt werden.

 

[blinddark]

Oki danke. Dann sieht das ja gut aus bei mir.

 

[Yippie]

Hi,

also mich hat's jetzt auch mit dem fehlenden Zugriff seit dem 1709 Update getroffen. Allerdings nach dem Aktivieren von SMB1, wurde das Problem behoben.

Anzumerken ist, dass ich auf allen meinen Synologys als mindest-SMB-Protokoll: SMB2 und als maximum: SMB3 nutze. Warum jetzt ausgerechnet die (Re-)Aktivierung von SMB1 (ausschließlich: SMB 1.0/CIFS-Client) das Problem behoben hat ist mir schleierhaft.

Ein Get-SmbConnection in einer Admin-Powershell brachte ausschließlich SMB 3.1.1 "Dialekte" zum Vorschein, also nix mit SMB1.

Ich glaube M$ hat da wieder einmal einen ziemlichen Bock geschossen. Win10 wird immer mehr beim Kunden getestet und verlässt wohl ohne eingehende Qualitätssicherung das Hause Microsoft.

Michael

 

[Paderborner]

Hallo zusammen!

ich habe auch das Problem mit dem 1709-Update auf einem der Rechner.
Wie lange dauert denn die Umstellung auf SMB2 oder höher? Ist das Laufwerk sofort wieder zu erreichen?
Und wie verhällt es sich mit den beiden Netzlaufwerken die auf das Home bzw. ein Netzlaufwerk? diese werden mit Hilfe von Gruppenrichtlinien auf meinem Windows-Server hergestellt.

Danke für eure Hilfe!

 

[dany]

Wie das CmdLet schon sagt, SmbServerConfiguration betrifft den SMB Server von Windows, und hat mit dem NAS Server nichts zu tun. Ein Windows 10 Client kann selber als SMB Server mit bis zu 30 Verbindungen auf einen Share fungieren. (Wer wissen will was für Shares er hat kann "Get-SmbShare" ausführen.) Wer alle Powershell Cmdlets für SMB anzeigen will der kann folgendes ausführen:

Get-Command –Module Smb* | Sort Noun, Verb

Wer SMBv1 Grundsätzlich nicht mehr nutzen will kann folgendes tun:

SMBv1 auf einem Windows 10 (Server) abschalten:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

SMBv1 auf Windows 10 (Client) abschalten:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

Anzeige der Clientverbindungen (vom Windows 10) zu einem Server

Get-SmbConnection

Anzeige der Clientverbindungen (zum Windows 10) Server

Get-SmbSession

Ein neustart des Clients ist sicher die sicherste Methode.

Ich bin der Meinung das ein Abschalten von SMBv1 auf einem NAS Sinn macht wenn man Geschäftsdaten oder externe Zugriffe hat. Für den Home-Bereich würde ich min/max SMB1 bis SMB3 lassen.n Windows handelt immer die höchstmögliche Version aus, d.h. es macht schon im Alltag einfacher wenn der Client auch noch SMBv1 kann. Es gibt genug Server (z.b. Uni, Ext. Firmen) die noch Ur-Alt Server in Betrieb haben.

Ich hatte vor ein paar Tagen das Problem das ein Windows 2012 R2 Server keine Shares mit SMBv2 (eines Linuxservers) und höher aurufen konnte. Ich konnte es mit einen Neustart oder dem neustart des Dienstes "Workstation/Arbeitsstationsdienst" beheben. Was man prüfen könnte wäre ob auch der SMB Zugriff via IP nicht geht: \\192.168.1.100\share

Was auch helfen kann, sind die ganzen Network Credentials zu löschen

net use * /DELETE

Gruss Dany

 

[tomdue]

Neustart vom Netzwerk-Stack ist die Problemlösung !

Hi,

also mich hat's jetzt auch mit dem fehlenden Zugriff seit dem 1709 Update getroffen. Allerdings nach dem Aktivieren von SMB1, wurde das Problem behoben.

Anzumerken ist, dass ich auf allen meinen Synologys als mindest-SMB-Protokoll: SMB2 und als maximum: SMB3 nutze. Warum jetzt ausgerechnet die (Re-)Aktivierung von SMB1 (ausschließlich: SMB 1.0/CIFS-Client) das Problem behoben hat ist mir schleierhaft.

Ein Get-SmbConnection in einer Admin-Powershell brachte ausschließlich SMB 3.1.1 "Dialekte" zum Vorschein, also nix mit SMB1.

Ich glaube M$ hat da wieder einmal einen ziemlichen Bock geschossen. Win10 wird immer mehr beim Kunden getestet und verlässt wohl ohne eingehende Qualitätssicherung das Hause Microsoft.

Michael

Ein Hinweis: Es ist nicht das Aktivieren von SMB1, welches die Magie bewirkt, sondern der Restart des Netzwerk-Stacks auf der Synology (wird bei einer Änderung neu gestartet). Genausogut kannst Du auch das Netzwerk auf der Windows-Maschine neu starten. Das Synology-NAS funktioniert dann wieder wie gewohnt --- bis zum nächsten Start oder Wakeup von Windows. Irgendwas geht beim Handshake schief und da ist sicher Microsoft schuld, denn mit 1703 läuft es problemlos.

 

[Yippie]

Ein Hinweis: Es ist nicht das Aktivieren von SMB1, welches die Magie bewirkt, sondern der Restart des Netzwerk-Stacks auf der Synology (wird bei einer Änderung neu gestartet). Genausogut kannst Du auch das Netzwerk auf der Windows-Maschine neu starten. Das Synology-NAS funktioniert dann wieder wie gewohnt --- bis zum nächsten Start oder Wakeup von Windows. Irgendwas geht beim Handshake schief und da ist sicher Microsoft schuld, denn mit 1703 läuft es problemlos.

Aha, danke für die Aufklärung. Ich bilde mir aber ein, dass ich seither keine Probleme mehr hatte, selbst nach längerer Arbeit mit/ohne Abmeldung und Neustarts dazwischen.
Aber da kann ich mich natürlich täuschen. Es wird sich dann wohl heute zu Hause zeigen was jetzt Sache ist...

Aber im Grund genommen gebe ich dir auch recht und es ist m.E. Microsofts Schuld, dass hier Mal wieder Müll abgeliefert wurde.

Michael

 

[Yippie]

Ich hatte vor ein paar Tagen das Problem das ein Windows 2012 R2 Server keine Shares mit SMBv2 (eines Linuxservers) und höher aurufen konnte. Ich konnte es mit einen Neustart oder dem neustart des Dienstes "Workstation/Arbeitsstationsdienst" beheben. Was man prüfen könnte wäre ob auch der SMB Zugriff via IP nicht geht: \\192.168.1.100\share

Auf ein Share via IP-Adresse zuzugreifen, führt auch nicht zum Ziel, da ich genau das schon seit längerem so mache, sowohl ad-hoc als auch per Laufwerksmapping via Group-Policies. Weder diese Variante noch die Verwendung von Server-Netbios Namen, auch mit Domain-Angabe, hilft hier nicht weiter.

Michael

 

[NSFH]

Hatte jetzt dieses Problem mit einem Linux Server und Win10.
Für sofortige Abhilfe hat in Samba die Einstellung "server max protocol = SMB3" gesorgt.
Danach lief auf allen win10 Clients wieder der Nw Zugriff.
Evtl mal in der Syno das Minimum Protocol auf SMB2 setzen oder komplett auf SMB3 wechseln, ist sowieso sicherer.
Habe bis jetzt noch keine Syno mit Win10 Creator update um es selber zu testen.

Dann mal checken: Systemsteuerung -> Programme und Features -> Windows Features aktivieren oder deaktivieren nachschauen und dort „Unterstützung für die SMB 1.0 / CFIS-Dateifreigabe" deaktivieren.
Bei updates lässt Creator SMB1 aktiv, bei Neuinstallationen gibt's nur noch SMB3.
Hier sind alle Produkte die SMB1 noch nutzen aufgelistet. blogs.technet.microsoft.com

 

[al3x82]

Für sofortige Abhilfe hat in Samba die Einstellung "server max protocol = SMB3" gesorgt.
Danach lief auf allen win10 Clients wieder der Nw Zugriff.
Evtl mal in der Syno das Minimum Protocol auf SMB2 setzen oder komplett auf SMB3 wechseln, ist sowieso sicherer.

Das ist bei jedem Syno-NAS eigentlich schon automatisch in der Samba-Konfiguration hinterlegt, sobald man SMB3 als maximales Protokoll festlegt.
Hab das gerade bei meiner DS916+ nochmal überprüft:

/etc/samba/smb.conf:

[global]
min protocol=NT1
max protocol=SMB3

Das hilft allerdings nur so lange, bis die Windows-Maschine neugestartet wird. Hier besteht also kein direkter Zusammenhang mit dieser Einstellung.

Einzige dauerhafte Abhilfe ist aktuell, den SMB1-Client auf Windows zu aktivieren oder auf 1703 zurück zu gehen.

 

[NSFH]

Was passiert, wenn man in der Syno SMB3 als einziges Protokoll zulässt und es in WIN tatsächlich (überprüft!) deaktiviert hat?
Niemand schreibt hier, wie sein WIN10 aktualisiert wurde, denn daran hängt, ob SMB1 überhaupt noch vorhanden ist (ja beim update) oder SMB1 komplett deaktiviert ist( quasi Neuinstallation).

 

[NSFH]

Mal einige Zusatzinfos, da hier Server- und Clientseitiges SMB durcheinander geworfen wird:

https://support.microsoft.com/de-de...-smbv1-smbv2-and-smbv3-in-windows-and-windows
Wenn man weiter auf seine Fritzbox via SMB v1 zugreifen will, dann sollte man nur die _Server_-Seite von SMB v1, also die Freigabe eigener Dateien, deaktivieren. Im Falle von Windows 7/8/10 reicht es, lediglich einen einzigen Registryeintrag zu ändern:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
SMB1=0
Dann den Dienst "Server" neu starten. Die _Client-Seite, also die Fähigkeit, selbst via SMB v1 woanders zuzugreifen wird durch diese Änderung nicht angetastet. Ein Zugriff auf z.B. die Fritzbox bleibt weiterhin möglich.
Wenn man dagegen bei Windows 10 über die Featureeinstellungen SMB v1 abschaltet, dann hat man die Client- und die Serverfunktionalität abgeschaltet, was evtl. nicht gewünscht ist.
Mit dem Abschalten der Serverfunktionalität für SMB v1 hat man privat schon die Sicherheit erhöht, da Schadsoftware nun nicht mehr via SMB v1 den eigenen PC gefährden kann.

Was nun gerade aktiv auf dem WIN10 PC läuft kann man mit Admin-Rechten mit der Powershell schnell überprüfen: Get-SmbConnection

 

[al3x82]

Im Falle von Windows 7/8/10 reicht es, lediglich einen einzigen Registryeintrag zu ändern: [...]
Wenn man dagegen bei Windows 10 über die Featureeinstellungen SMB v1 abschaltet, dann hat man die Client- und die Serverfunktionalität abgeschaltet, was evtl. nicht gewünscht ist.

Seit Win10 1709 lassen sich in den Windows-Features client- u. serverseitiges SMBv1 getrennt voneinander de-/aktivieren. Siehe mein Screenshot hier.

Was passiert, wenn man in der Syno SMB3 als einziges Protokoll zulässt und es in WIN tatsächlich (überprüft!) deaktiviert hat?

Dann funktioniert es mit abgeschaltetem clientseitigen SMBv1 nach einem Windows-Neustart noch immer nicht. Die Verbindung wird immer über SMBv3.1.1 aufgebaut, das haben wir schon in diesem Thread festgestellt (s. Screenshot hier). Trotzdem bewirkt das Deaktivieren des SMBv1-Clients dieses merkwürdige Verhalten in 1709.

Niemand schreibt hier, wie sein WIN10 aktualisiert wurde, denn daran hängt, ob SMB1 überhaupt noch vorhanden ist (ja beim update) oder SMB1 komplett deaktiviert ist( quasi Neuinstallation).

Ich habe beides ausprobiert: Update meines 1703 (wo SMBv1 bereits deaktiviert war in den Features) sowie eine komplette Neuinstallation in einer VM (bei der SMBv1 defaultmäßig deaktiviert ist). Identisches Verhalten.

 

[NSFH]

Da meine geschilderten Veränderungen an einem normalen Linux-Server funktionieren vermute ich jetzt allerdings, dass das Problem bei der Syno und nicht bei Win10 liegt.

 

[al3x82]

Hast Du auf der Linux-Kiste den gleichen Account mit gleichem Passwort angelegt? Das Problem tritt nämlich (bei mir zumindest) nur auf, wenn man sich ohne Anmeldung direkt verbinden kann, weil User und Passwort identisch sind. Problem kann natürlich auf Synology-Seite liegen - wär mir sogar lieber, da ich Synology für kompetenter als Microsoft halte, was solche schwer nachzustellenden Bugs angeht

 

[DustFireSky]

Unter Linux Mint 18.2 X64 habe ich keinerlei Probleme.
Auch unter Windows 10 1709 selbst scheint erstmal alles okay zu sein.

Allerdings gibt es trotzdem ein Problem und dann greifen Eure Beobachtungen. Wenn ich im Netzwerk über PXE boote und dann ein WINPE lade und dort mit "net use bla bla" ein Netzlaufwerk mounten will klappt das zwar, um zum Beispiel ein Windows Setup anzustoßen, allerdings vergisst die Setup.exe so wie es aussieht die Pfade oder einfach die Fähigkeit auf passivaufgerufene Dateien zuzugreifen.

Grobe Ordnerstruktur Win Setup (Mimimalistisch!)
Sources
Setup.exe

Die Setup.exe startet zwar, kann aber auf die install.esd im Ordner Sources nicht zugreifen.



Meldung => Datei existiert nicht. Natürlich existiert diese. Wenn ich den SMB Dienst neustarte geht wieder alles.

Ich habe das mal mit Wiedergabelisten getestet. Da ist es genau so. Sobald eine Datei eine andere aufruft klappt dies meistens nicht. Einzelne Dateien wie Videos hingegen schon. Ich bin allerdings auch kein Experte, weißgott nicht! Meine Beobachtungen.

EDIT:// Ich habe den Screenshot hinzugefügt. Wieder das Problem. Der Witz ist, das ich gerade über SMB einen Film gucke.... Das funktioniert dann noch, wenn ich den Fehler erhalte.

 

[al3x82]

Ich glaube leider mittlerweile auch, dass der Fehler von Synology verursacht wird. Ich hab mir jetzt die Arbeit gemacht und nochmal ein Debian aufgesetzt mit Samba. Hab den gleichen Benutzer wie im Windows angelegt und im Prinzip die Freigaben meines NAS nachgespielt. Hier kann ich den Fehler nicht nachstellen...

Irgendetwas muss Microsoft mit 1709 geändert haben, woran sich eine spezielle Konfiguration, die Synology im Einsatz hat, stört. Aber ich krieg nicht raus, woran es liegen könnte...