7
Raspberry Share Zugriff mit Windows Client geht nicht (überall)
Guten Abend zusammen,
nun bräuchte ich auch mal eure Unterstützung.
Wir haben im Netzwerk einen Raspberry am Laufen, auf welchem sich ein Share befindet.
Es gibt Laborgeräte, welche dort ihre Daten ablegen. funktioniert.
Ein fixer Windows Client sollte diese Daten von diesem Share abholen, was aktuell leider nicht funktioniert.
Wir haben div. Windows Client (Domain Joined) getestet und unterschiedliche Ergebnisse.
- Ich bekommen einen Windows Fehlermeldung "Netzwerkfehler" blablabla konnte nicht zugegriffen wurden. Siehe Foto "Share1"
- Ich bekomme einen "Explorer" Fehler; Die Datei wurde nicht gefunden....... siehe Foto "Share2"
- Und zu guter letzt gibt es Clients, bei welchen erfolgreich das Loginfenster kommt und ich kann mich ganz normal verbinden. Ist z.B. ein Windows 11 (mein Client); (ein andere Win 11 geht wiederum nicht)
Zur Umgebung:
-Generell sind bei uns kein Windows Firewalls aktiviert.
-Es gibt innerhalb vom Netzwerk aktuell ebenfalls keine Firewall.
-Ich habe div. Win 10 21H2 + 22H2 + Win 11 23H2 getestet; der eine geht, die meisten nicht
-Pingen können alle Client diesen Raspberry !!
-SSH zugriff geht ebenfalls von überall !!
-Auffallend: Server, welche nicht Domain gejoind sind, scheinen alle zu funktionieren. (getestet mit WS2022)
-Noch ein Finding: Domain Joined Server funktionieren, wenn sie älter WS 2019 sind; also 2008-2016 geht problemlos!! 2019+2022 gehen NICHT (Es sind alle in der gleichen OU und somit identische GPO's)
Ach ja, noch ein wichtiger Hinweis: Ich habe keinerlei Ahnung von einem Raspberry
(Bei Fragen brauche ich detaillierte Angaben, wie ich mit SSH an die Info's komme)
Subnet und Gateway passen; mehrmals kontrolliert. Ping + SSH geht ja von überall.
Ich vermute irgend ein Reg-Key (Netzwerk-Sicherheit/Protokoll) macht mir hier das Leben schwer. Die Frage wäre nun welcher?
Vielen Dank für eure Unterstützung.
Gruss Roland
nun bräuchte ich auch mal eure Unterstützung.
Wir haben im Netzwerk einen Raspberry am Laufen, auf welchem sich ein Share befindet.
Es gibt Laborgeräte, welche dort ihre Daten ablegen. funktioniert.
Ein fixer Windows Client sollte diese Daten von diesem Share abholen, was aktuell leider nicht funktioniert.
Wir haben div. Windows Client (Domain Joined) getestet und unterschiedliche Ergebnisse.
- Ich bekommen einen Windows Fehlermeldung "Netzwerkfehler" blablabla konnte nicht zugegriffen wurden. Siehe Foto "Share1"
- Ich bekomme einen "Explorer" Fehler; Die Datei wurde nicht gefunden....... siehe Foto "Share2"
- Und zu guter letzt gibt es Clients, bei welchen erfolgreich das Loginfenster kommt und ich kann mich ganz normal verbinden. Ist z.B. ein Windows 11 (mein Client); (ein andere Win 11 geht wiederum nicht)
Zur Umgebung:
-Generell sind bei uns kein Windows Firewalls aktiviert.
-Es gibt innerhalb vom Netzwerk aktuell ebenfalls keine Firewall.
-Ich habe div. Win 10 21H2 + 22H2 + Win 11 23H2 getestet; der eine geht, die meisten nicht
-Pingen können alle Client diesen Raspberry !!
-SSH zugriff geht ebenfalls von überall !!
-Auffallend: Server, welche nicht Domain gejoind sind, scheinen alle zu funktionieren. (getestet mit WS2022)
-Noch ein Finding: Domain Joined Server funktionieren, wenn sie älter WS 2019 sind; also 2008-2016 geht problemlos!! 2019+2022 gehen NICHT (Es sind alle in der gleichen OU und somit identische GPO's)
Ach ja, noch ein wichtiger Hinweis: Ich habe keinerlei Ahnung von einem Raspberry
(Bei Fragen brauche ich detaillierte Angaben, wie ich mit SSH an die Info's komme)Subnet und Gateway passen; mehrmals kontrolliert. Ping + SSH geht ja von überall.
Ich vermute irgend ein Reg-Key (Netzwerk-Sicherheit/Protokoll) macht mir hier das Leben schwer. Die Frage wäre nun welcher?
Vielen Dank für eure Unterstützung.
Gruss Roland
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 32439781504
Url: https://administrator.de/forum/raspberry-share-zugriff-mit-windows-client-geht-nicht-ueberall-32439781504.html
Ausgedruckt am: 21.12.2024 um 11:12 Uhr
7 Kommentare
Neuester Kommentar
Moje.
Erstens fehlt der Share-Name!
Zweitens Stichwort deaktiviertes SMB1 falls der Raspberry schon älter ist und auch
"Local Policies > Security Options > Network Security: LAN Manager authentication level" sollten als Info reichen, Rest kannst du damit ergoogeln.
Gruß Strods
Erstens fehlt der Share-Name!
Zweitens Stichwort deaktiviertes SMB1 falls der Raspberry schon älter ist und auch
"Local Policies > Security Options > Network Security: LAN Manager authentication level" sollten als Info reichen, Rest kannst du damit ergoogeln.
Generell sind bei uns kein Windows Firewalls aktiviert
Autsch.Gruß Strods
1
Der Feigabename des samba-Shares fehlt.
Alles in allem wäre auch die Samba Konfig auf dem RasPi hilfreich für ein zielführendes Troubleshooting!
Ein einfache öffentliche Freigabe eines SMB Ver.2 Shares sähe z.B. so aus:
Das Share Verzeichnis auf dem RasPi muss dann mit chown -R nobody:nogroup /srv/samba/public/ Noch auf einen entsprechenden Samba User gesetzt sein und mit chmod 2770 /srv/samba/public/ die entsprechenden Dateirechte bekommen.
Leider fehlt die Info wie das bei dir eingerichtet ist und ob du auf den Winblows Rechnern dieses Share z.B. manuell mit \\<Raspi_IP>\Public (man achte auf den Share Namen!!) z.B. im Suchpfad mounten kannst.
Wenn auf dem RasPi auch ein AVAHI (mDNS) Daemon rennt (was in der Regel Default ist), dann wird der RasPi auch netzwerkweit mit seinem Namen im Netzwerk allen Windows Rechnern automatisch bekannt gegeben.
Ob das der Fall ist kannst du mit avahi-browse -a prüfen sofern du vorher mit apt install avahi-utils Die AVAHI Utilities auf dem RasPi installiert hast.
Ein einfache öffentliche Freigabe eines SMB Ver.2 Shares sähe z.B. so aus:
[global]
min protocol = SMB2
[public]
# Gastzugang ohne Passwort
path = /srv/samba/public/
comment = Public
read only = no
guest ok = yes
guest only = yes Leider fehlt die Info wie das bei dir eingerichtet ist und ob du auf den Winblows Rechnern dieses Share z.B. manuell mit \\<Raspi_IP>\Public (man achte auf den Share Namen!!) z.B. im Suchpfad mounten kannst.
Wenn auf dem RasPi auch ein AVAHI (mDNS) Daemon rennt (was in der Regel Default ist), dann wird der RasPi auch netzwerkweit mit seinem Namen im Netzwerk allen Windows Rechnern automatisch bekannt gegeben.
Ob das der Fall ist kannst du mit avahi-browse -a prüfen sofern du vorher mit apt install avahi-utils Die AVAHI Utilities auf dem RasPi installiert hast.
Hallo zusammen,
danke für die ersten Hinweise.
1. der ShareName ist nicht zwingend und tut eigentlich nichts zur Sache.
bei den Clients, wo es funktioniert, sieht er den Sharename nach dem Login automatisch.
2. SMB1 beim Windows Server ist NICHT das Problem - habe ich nun ausgetestet
3. LAN Manager authentication level ist auch nicht das Problem - Es funktioniert bei den Clients wo es geht, auch mit der höchsten Einstellung "send ntlmv2 response only. refuse lm & ntlm"
Ich könnte mir aber ebenfalls sehr gut vorstellen, dass es hier: Local Policies > Security Options > Network Security etwas sein müsste
4. smb.conf
comment = Elexis device result
path = /srv/samba/elexis-device
valid users = @20950
browsable = yes
writable = yes
read only = no
only guest = no
bezüglich "min protocol = smb2" möchte ich ungern umstellen, da wie geschrieben "doofe" Laborgeräte darauf schreiben. Keine Ahnung, ob die v2 können/kennen.
(wer sich mit Medizinalgeräte etwas auskennt, weiss, dass hier äusserst konservativ gearbeitet wird; da dauern Änderungen leider Jahrzehnte !!!)
Noch weitere Ideen die helfen könnten??
Vielen Dank schon mals im vorraus.
Gruss Roland
danke für die ersten Hinweise.
1. der ShareName ist nicht zwingend und tut eigentlich nichts zur Sache.
bei den Clients, wo es funktioniert, sieht er den Sharename nach dem Login automatisch.
2. SMB1 beim Windows Server ist NICHT das Problem - habe ich nun ausgetestet
3. LAN Manager authentication level ist auch nicht das Problem - Es funktioniert bei den Clients wo es geht, auch mit der höchsten Einstellung "send ntlmv2 response only. refuse lm & ntlm"
Ich könnte mir aber ebenfalls sehr gut vorstellen, dass es hier: Local Policies > Security Options > Network Security etwas sein müsste
4. smb.conf
- Elexis-device results directory
comment = Elexis device result
path = /srv/samba/elexis-device
valid users = @20950
browsable = yes
writable = yes
read only = no
only guest = no
bezüglich "min protocol = smb2" möchte ich ungern umstellen, da wie geschrieben "doofe" Laborgeräte darauf schreiben. Keine Ahnung, ob die v2 können/kennen.
(wer sich mit Medizinalgeräte etwas auskennt, weiss, dass hier äusserst konservativ gearbeitet wird; da dauern Änderungen leider Jahrzehnte !!!)
Noch weitere Ideen die helfen könnten??
Vielen Dank schon mals im vorraus.
Gruss Roland
Nach was zum "Studieren" Siehe Screenshot.
Problem scheint:
Der Windows-Client versucht "einfach" mit dem angemeldete Domain User zu verbinden, OHNE das ein Loginfenster kommt.
Der angemeldete User kann logischerweise NICHT funktionieren.
Wie "zwinge" ich Windows dazu, dass er nach den Logindaten fragt?
Hoffe dies bringt noch jemand auf eine Idee.
Roland
Problem scheint:
Der Windows-Client versucht "einfach" mit dem angemeldete Domain User zu verbinden, OHNE das ein Loginfenster kommt.
Der angemeldete User kann logischerweise NICHT funktionieren.
Wie "zwinge" ich Windows dazu, dass er nach den Logindaten fragt?
Hoffe dies bringt noch jemand auf eine Idee.
Roland
Hallo zusammen,
wir konnten das Problem lösen, wenn auch nur mit einem Workaround.
Die Logindaten über die Anmeldeinformationsverwaltung hinterlegt und alles ist gut. siehe Foto.
Falls jemand trotzdem noch darauf kommt, warum bei den einen Win-Clients nach dem Login gefragt wird und bei den anderen nicht, wäre immer noch interessant.
Danke
Gruss Roland
wir konnten das Problem lösen, wenn auch nur mit einem Workaround.
Die Logindaten über die Anmeldeinformationsverwaltung hinterlegt und alles ist gut. siehe Foto.
Falls jemand trotzdem noch darauf kommt, warum bei den einen Win-Clients nach dem Login gefragt wird und bei den anderen nicht, wäre immer noch interessant.
Danke
Gruss Roland
1
Und zu guter Letzt nun auch noch den richtigen Key ( AllowInsecureGuestAuth ), und somit Lösung gefunden, der das Login Fenster wieder erscheinen lässt. Siehe Foto.
Dieser Wert habe ich bei den WS2022 (nicht Domain Joined) ebenfalls gesetzt, weil ich dies dort zwingend benötige. Deshalb funktionierten diese beim Testen problemlos.
Und alte Windows Server vor 2019 eben auch.; da gab es den Key vermutlich noch nicht.
Warum mein Win 11 ohne diesen Key funktioniert ist mir noch ein Rätsel, was mir aber jetzt auch wirklich schnuppe ist.
Dieser Wert habe ich bei den WS2022 (nicht Domain Joined) ebenfalls gesetzt, weil ich dies dort zwingend benötige. Deshalb funktionierten diese beim Testen problemlos.
Und alte Windows Server vor 2019 eben auch.
; da gab es den Key vermutlich noch nicht.Warum mein Win 11 ohne diesen Key funktioniert ist mir noch ein Rätsel, was mir aber jetzt auch wirklich schnuppe ist.
1
