RedDiabolo Das mit der hosts-Datei hast du auch versucht?
![](https://forum.qnapclub.de/wsc/images/avatars/1d/1503-1d71120e4c56310f2eccd488105cd61bd9e5de9a.png)
Win10 - Netzlaufwerk verbinden ist bei älteren NAS nicht mehr möglich?
- RedDiabolo
- Unerledigt
-
-
Ja, auch die hosts Datei habe ich angepasst. Das hatte ich ohnehin schon seit Win7 drinnen, da dort die NetBios Namen nicht richtig aufgelöst wurden.
Mit dem Umstieg auf Win10 hatte es Anfangs auch ohne Eintrag in der hosts funktioniert, irgendwann seit ein paar Wochen dann nicht mehr ...
-
Funktioniert denn ein Netzlaufwerk //IPx.xxx.xxx.xxx/Freigabe ?
-
Nö, weder mit NETBIOS Name, noch mit der IP. Ist von daher also (fast) egal, ob ich in der hosts Datei einen extra Eintrag für die NAS mache, oder nicht.
PS.: Am Win-System sind die Freigaben mit Backslash '\' und nicht Slash '/' einzurichten. Oder wolltest du absichtlich die Web-Schreibweise verwenden?
-
Am Win-System sind die Freigaben mit Backslash '\' und nicht Slash '/' einzurichten.
Sorry, mein Fehler
-
Bei mir ging das so:
Netzlaufwerke, da vorher die entspr. NAS auswählen und dann einfach das entspr. Laufwerk verbinden.
Da wird dann nach dem Anmeldenahmen und Passwort der NAS gefragt, das wars dann schon.
PS. Bei mir war am PC unter Windows 10 standardmässig SMPT Deaktiviert, das war alles.
Die entpr. NAS ist jetzt wieder für Windows 10 sichtbar.
Hatte also bei mit mit SMB 1.0 nix zu tun.
War eine banale Sache, unter Windows Features SNMP einschalten und gut.
-
das wars dann schon.
Wenn's so einfach wäre, hätte ich diesen Threat gar nicht aufgemacht
Habe ich ja schon im Post #20 geschrieben, dass keine der mir bekannten "Workarounds" funktionieren.
Freue mich trotzdem, dass es bei dir "so einfach" geht, bei den meisten die dieses Problem haben hilft der QFinder auch nicht weiter. Schließlich macht er nichts anderes als ein 'net use' Befehl ...
-
Wenn SMB zickt wieso nicht NFS. Vielleicht nicht die perfekte Lösung aber zumindest als momentaner Workaround.
-
Hmm, ja, habe mir deinen Artikel nochmals durchgelesen und mich gewundert, weshalb es nicht funktioniert, wenn ich doch bereits NFS am Client aktiviert habe …
Da muss ich zusätzlich in der NAS extra bei den Freigaben auch das NFS berechtigen. Wobei ich jetzt nicht weiß was die "SQUASH" Options sind?
Die Ordner sehe ich damit im Explorer und kann auch darauf zugreifen. Als Netzlaufwerk kann ich sie trotzdem nicht verbinden.
(Die Fehlermeldung ist auch besonders aussagekräftig, oder?)
2018-12-10 23_48_06-Movie New.png
Als Workaround könnte ich es mal so lassen, aber so richtig "warm" werde ich damit erst, wenn ich auch ein Netzlaufwerk darauf verbinden kann
-
Ja, sagt nicht wirklich was aus. Aber immerhin sind mir die unerwarteten Fehler lieber, als die Fehler die MS sogar erwartet hat.
Versuch mal no_root_squash
Quelle: https://wiki.ubuntuusers.de/NFS/
root_squash
Weist alle Anfragen der UID/GID 0 auf die UID/GID anonymous zu. Zu beachten ist, dass damit andere sensible bzw. mächtige UserIDs wie etwa " bin
" oder "staff
" nicht geändert werden.X no_root_squash
Legt man als Nutzer root
per NFS Dateien oder Verzeichnisse an, werden diese standardmäßig dem Nutzernobody
zogeordnet ('root_squash'). Um dieses Sicherheitsmerkmal von 'root_squash' zu umgehen und die, vom Userroot
geschriebenen Daten, auf dem Server nicht auf einen anderen User als ihn selbst zu mappen (UID/GID 0 bleiben erhalten), verwendet man den Parameter 'no_root_squash'.- all_squash
Ordnet alle UserIDs dem Nutzer anonymous
zu. Nützlich für NFS-exportierte öffentliche FTP-Verzeichnisse oder News-Spool-Verzeichnisse.- anonuid
anongid
Diese Option setzt die anonyme User- und Gruppen-ID explizit auf die angegebenen Werte. Diese Option ist primär für PC/NFS Clients gedacht, wo davon ausgegangen wird, dass alle Nachfragen von einem bestimmten Rechner immer von einer Person kommen. Beispiel: /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
-
Haben wir hierzu etwas als Lösung gefunden, da ich ebenso mit den QNAP Netzlaufwerken auf einem NAS kein Zugriff habe?
Danke
-
Win10 unterstützt nicht mehr die alte unsichere SMB Version. Ganz alte QNAP funktionieren aber leider nur damit. Man kann SMB 1 aber wieder im Windows erlauben.
-
Haben wir hierzu etwas als Lösung gefunden,
Was bedeutet „alt“ in diesem Zusammenhang?
Welche QTS Version?
-
so mal als kleine Bemerkung: alt = QTS 4.2.5 geht nicht, QTS 4.3.3 geht
konnte mit der 4.3.3 auf dem TS419P+ das "SMB1-Feature" unter Win10 wieder deaktivieren.
-
Liegt aber nicht an der SMB1. Bei meiner alten NAS (4.1.4) ist SMB2.1 aktiv, trotzdem will Win10 damit nicht ...
-
ich hatte unter 4.2.5 auch vermeidlich SMB2.1 aktiv, aber Verbindung gab es trotzdem nur mit dem aktivierten "SMB1-Feature". Vielleicht gibt es da ein Problem mit der Aushandlung und QTS hat sich nicht "kompatibel genug" gemeldet.
-
Ich habe jetzt aus Spass bei mir auch mal nachgesehen, meine älteste QTS Version hier ist leider "nur" eine 4.2.6 Build 20180711.
Mein Win 8.1 verbindet sich zu allen NAS mit SMB v2.1 (wie erwartet), der Win 10 ebenfalls.
War auch kein Wunder, aich bei FW 4.3.3 ist als default noch SMB 2.1 als höchste Version eingestellt.
Ich habe das auf einem NAS nun auf SMB 3 geändert, nun sagt mit Win 8 das er mit SMB 3.0.2 zugreift, Win 10 meldet SMB 3.1.1 .
Ältere FW habe ich leider nicht, bzw. ich möchte das eine NAS auch nur ungern mit einer älteren FW versehen.
Gruss
-
-
Ja, aber für die „älteren“ NAS um die es lt Threadtitel geht gibt es ja kein 4.3.5.
-
Stimmt schon. Wollte damit nur untermauern, dass der Verbindungsaufbau wohl nicht immer automatisch mit der höchsten Version zustande kommt. Wieso sollte man ansonsten eine solche Funktion einbauen?