Laptop findet meinen Desktop im Netzwerk nicht

Denxu

Cadet 4th Year
Registriert
Juli 2021
Beiträge
125
Hallo folgende Situation habe ich. Ich benutze einen Desktop und einen Laptop für das Arbeiten. Zuhause möchte ich Dateien über das Netzwerk verschieben.

Gehe ich auf meinem Desktop aufs Netzwerk finde ich den Laptop und kann mich einloggen und Dateien verschieben.
Vom Laptop aus finde ich allerdings meinen Desktop nicht.

Obwohl beide im Netzwerk sichtbar sind. Im Grunde kann ich auch Dateien verschieben, wenn ich von meinem Desktop anmelde, trotzdem verstehe ich nicht, wieso mein Laptop meinen Desktop nicht im Netzwerk findet. Beide haben Windows 11 installiert.
Desktop ist per Lan verbunden. Habe aber auch die Kommunikation über das Wlan probiert.
Laptop ist per Wlan im Netzwerk.

Kann mir das jemand erklären?
 
Ja, diese "Suche" ist:
1. sehr unzuverlässig und
2. basiert diese auf veralteten und abgekündigten Technologien.

Man kann zwar (noch) diese alten Abhängigkeiten wieder aktivieren aber eigentlich gehört die ausgerottet und abgeschafft da die Grundlage eben veraltete langsame und unsichere Protokolle sind für die es auch nicht mehr wirklich Sicherheitsupdates geben wird falls neue Lücken auftauchen. Ja, für Endanwender ist das 'ärgerlich', aber es gibt genug Alternativen:
Explorer öffnen, in die Adressleiste den Namen des nicht auffindbaren Systems eingeben und so gezielt aufrufen anstatt jedes Mal über die Suche zu gehen. Wenn du dann das Zielverzeichnis auch öffnest, kannst im Datei Explorer oben links auf "An Schnellzugriff anheften" klicken. Dann bleibt dauerhaft ein Eintrag links im Datei Explorer im Schnellzugriff. Für die Zukunft heißt es dann: Explorer öffnen, ein Klick und du bist am Ziel.

Wenn du mehr Details willst: Forensuche verwenden. Gibt gefühlt hunderte Threads zum Thema der nicht funktionierenden "Netzwerkumgebung suchen" Funktion wo mehr als einmal die Details erklärt werden.
 
  • Gefällt mir
Reaktionen: Raijin, Denxu und Ja_Ge
Hi...

Denxu schrieb:
[...] wieso mein Laptop meinen Desktop nicht im Netzwerk findet.
[...]
Kann mir das jemand erklären?
Die Anbindungsmethode für die Netzwerkverbindung ist eigtl. dafür unerheblich, allerdings mag doch in gewisser Abhängigkeit evtl. eine sicherheitsrelevante Einstellung bzgl. WLAN vom Betriebssystem dafür ursächlich sein - schonmal dazu die Firewall-Einstellung (Netzwerkprofiltyp) geprüft?
Ansonsten ist das auch mit Bildern in dieser Win-FAQ-Anleitung beschrieben.​
 
Würde das Problem auch nur verschieben, da SMBv1 und NetBIOS halt langsam aber sicher wegfallen sollen. In paar Monaten/Jahren, wenn MS dann endgültig das Feature entfernt, steht der TE halt wieder hier...
 
  • Gefällt mir
Reaktionen: Raijin
Da bin ich voll bei @snaxilian
Alle paar Tage taucht hier ein Thread dieser Art auf. Die Lösung ist immer dieselbe: Entweder direkt über den Namen oder die IP des Ziels im Explorer gehen oder ein Netzlaufwerk anbinden. Ersteres hat @snaxilian oben schon erklärt, das Netzlaufwerk funktioniert wie folgt:

Start --> cmd
--> net use x: \\NameOderIPdesZiels\Freigabe /user:Benutzername /persistent:yes

Nach Enter wird das Passwort des angegebenen Benutzers abgefragt. Den Laufwerksbuchstaben x: kann man frei wählen, je nachdem welche Laufwerksbuchstaben auf dem lokalen System noch frei sind. Unter diesem Buchstaben kann man künftig auf die Freigabe zugreifen - so als wäre es ein internes Laufwerk (zB C: ). Die letzte Option bedeutet, dass das Laufwerk persistent ist, also auch nach einem Reboot erhalten bleibt. Zugreifen kann man aber natürlich nur, wenn das Ziel eingeschaltet ist, sonst wird das Laufwerk mit einem roten x markiert (und automatisch verbunden, wenn das Ziel irgendwann on geht).
 
snaxilian schrieb:
[...] da SMBv1 und NetBIOS [...]
Was hat das damit zu tun? 🤔
SMBv1 ist in W10 seit dem Creators Fall-Update eh standardmäßig deaktiviert und NetBIOS wird im lokalen Netzverbund vom DHCP-Server bereitgestellt - es ging um den Netzwerkprofiltyp (Privat oder Öffentlich), der eben Auswirkungen auf die Firewall-Einstellungen (f. Benutzer-/Netzwerkerkennung, Dateifreigabe) hat.

Hmm... also, mglw. irre ich ja (entscheidend), aber wenn das Zielgerät eine eingehende Verbindung nicht zulässt, kann man doch solang' man will die Verbindung mittels Name oder IP bzw. net use-Kommando versuchen vom anfragenden Quellgerät zu etablieren.
Ich glaub' ja, dass hier genau die Benutzerkontoanmeldung ohne Kennwort beim Zugriff zum Tragen kommt und damit verhindert.​
 
User007 schrieb:
Was hat das damit zu tun? 🤔
Nichts mit dem was du dem TE erklärst aber mit dem Problem des TEs. Der TE hat kein Zugriffsproblem sondern nutzt die unzuverlässige "Netzwerkumgebung" von Windows und die basiert auf NetBIOS und SMBv1.
User007 schrieb:
SMBv1 ist in W10 seit dem Creators Fall-Update eh standardmäßig deaktiviert
Bei Upgrades wird das Feature aber nicht automatisch deaktiviert, sondern bleibt erst einmal aktiv. Erst wenn es dann eine gewisse Zeit nicht genutzt wird, fliegt es runter, zumindest bei Win 10 Home & Pro.
https://learn.microsoft.com/de-de/w...oot/smbv1-not-installed-by-default-in-windows
Anyway, offenbar gab es ein Missverständnis und wir haben vielleicht aneinander vorbei geredet.
Der TE hat offenbar mit der Nutzung des Schnellzugriffs eine Lösung gefunden, zumindest deute ich das aus dem Like meines Beitrags und dass seitdem keine weitere Reaktion oder Rückfrage des TE kam.
 
Hmm... sorry, aber ich würd' Deine "Beschreibung" eher als Optimierung des Workflow interpretieren und bzgl. der Suche sowie Nutzung von als sog. "deprecated" gekennzeichneten Protokollen hat sie ja durchaus auch Allgemeingültigkeit, aber eine wirkliche "Erklärung" (wie vom TE angefragt) seh' ich da ehrlich gesagt nicht. 🤷‍♂️
snaxilian schrieb:
Bei Upgrades wird das Feature aber nicht automatisch deaktiviert, sondern bleibt erst einmal aktiv.
Ok, das war mir tatsächlich so nicht bewußt - danke für den Hinweis und verlinkten Artikel.
Zeigt für mich allerdings - auch wieder zu diesem Thema - so 'ne Inkonsequenz (und damit einhergehend Inkonsistenz) in der Umsetzung von M$. 🤨

Für mich zeigt sich zum Problem des TE halt Folgendes relevant:
Der TE hat ein mobiles Endgerät (Laptop), das via WLAN eine Netzverbindung etabliert hat - wenn dies erstmalig eingerichtet wird, bekommt man, wie in meinem verlinkten M$-Artikel beschrieben, einen entsprechenden Hinweis, dass der Netzwerkprofiltyp standardmäßig auf "Öffentlich" gestellt wird.
Ist doch durchaus schon (logisch) nachvollziehbar, dass aus Sicherheitsaspekten dieser (Mobil-)Rechner dann standardmäßig (ohne besondere Authorisierung) erstmal keinen Zugang zu einem anderen (stationären Desktop-)Gerät mit dem Netzwerkprofiltyp "Privat" auch im gleichen lokalen Netzverbund erhält, es aber trotzdem "sieht".

Btw.:​
snaxilian schrieb:
Der TE hat offenbar mit der Nutzung des Schnellzugriffs eine Lösung gefunden, [...]
Ja, das würd' mich interessieren, aber ich führe das eher darauf zurück, dass es meinen Beitrag zu dem Zeitpunkt noch gar nicht gab und er wohl bis dato hier noch nicht wieder "reingeschaut" hat - gleichwohl wäre eine Rückmeldung auch immer angebracht.​
 
Zurück
Oben