Windows 10 - 1709 hat Probleme mit Zugriff auf Synology

Status
Für weitere Antworten geschlossen.

blinddark

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

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
05. Mrz 2013
Beiträge
2.128
Punkte für Reaktionen
720
Punkte
154
Ich hab' gerade getestet, was ich gefunden hatte. Wie ich schon fast erwartet hab', hat das mit unserem Problem nichts zu tun.
 

mondfee

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

Benutzer
Sehr erfahren
Mitglied seit
30. Jun 2015
Beiträge
3.317
Punkte für Reaktionen
600
Punkte
174
Wie hast du die Abfrage ausgeführt?

Ja, über Powershell.

Zuerst mit SmbServerConfiguration die Einstellungen ausgeben lassen:
Rich (BBCode):
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

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.386
Punkte für Reaktionen
34
Punkte
68
Oki danke. Dann sieht das ja gut aus bei mir.
 

Yippie

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

Benutzer
Mitglied seit
15. Aug 2016
Beiträge
9
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
31. Mrz 2008
Beiträge
352
Punkte für Reaktionen
0
Punkte
22
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:

PHP:
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:
PHP:
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

SMBv1 auf Windows 10 (Client) abschalten:
PHP:
sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

Anzeige der Clientverbindungen (vom Windows 10) zu einem Server
PHP:
Get-SmbConnection

Anzeige der Clientverbindungen (zum Windows 10) Server
PHP:
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
PHP:
net use * /DELETE

Gruss Dany
 
Zuletzt bearbeitet:

tomdue

Benutzer
Mitglied seit
26. Apr 2014
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
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

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

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

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.067
Punkte für Reaktionen
552
Punkte
194
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
 
Zuletzt bearbeitet:

al3x82

Benutzer
Mitglied seit
04. Aug 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
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:

Rich (BBCode):
/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

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

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

Benutzer
Mitglied seit
04. Aug 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
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

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

Benutzer
Mitglied seit
04. Aug 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
22. Sep 2014
Beiträge
346
Punkte für Reaktionen
57
Punkte
34
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.

1.jpg

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. :rolleyes:

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.
 
Zuletzt bearbeitet:

al3x82

Benutzer
Mitglied seit
04. Aug 2016
Beiträge
10
Punkte für Reaktionen
0
Punkte
0
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...
 
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