[ricky007]

Hallo Leute,

habe hier einen frischen 2022 Server installiert. Seit Jahren habe ich ein Sambashare auf Linux (Debian 11) das meine Steamdatenbank beinhaltet. Die Freigabe ist public und erfordert keinerlei Auth. Mit Windows10 und Windows11 lässt sich die Freigabe ohne Hindernisse einbinden. Server 2022 meckert schon das man den Hostnamen richtig schreiben solle. Ping auf FQDN funktioniert.

Ich hab nun die SMB.conf versucht in alle möglichen Configs zu ändern. Leider ohne Erfolg. Egal mit oder ohne Auth., Server 2022 kommt nicht an den Server ran. Habt ihr ne Idee an was es liegen könnte? Wie kann ich dem Thema auf die Schliche kommen?

Ist ein Linuxserver Domainmitglied tut das ganze. Komisch oder?

Danke lg

[Stefan_der_held]

Zitat (ricky007: 22. Juli 2022 - 22:14)

Ich hab nun die SMB.conf versucht in alle möglichen Configs zu ändern.

Das ist immer eine geile Aussage

Ich frage mal so nebenbei: In welcher Version liegt das verwendete SMB-Protokoll vor? SMB 1.0 wird ohne weiteres nicht mehr von Windows unterstützt. Das müsste (auf allen Systemen - Clients sowie Server) noch in den Features dort aktiviert werden. Das ist aber nicht zu empfehlen da SMB 1.0 gravierende Sicherheitsrisiken birgt.

[Stef4n]

Der SMB V1 Gedanke liegt natürlich hier nahe, aber wenn man das Protokoll ja schon unter Win10 & 11 das wieder aktivieren muss, dann wird ricky das sicher auch unter Win2022 schon versucht haben.

Könnte mir vorstellen, dass die Ursache hier in der Authentifizierung liegt und Win2022 diese Public Folder Geschichte nicht unterstützt.
Oder vielleicht muss der Samba Server mal auf den neusten Stand gebracht werden.

[ricky007]

Hallo Leute,

vielen Dank mal für eure Antworten. Hatte nun endlich mal Zeit beim Thema weiter zu suchen. Hier mal die Eckdaten:

Server: Proxmox Debian Buster
Sambaversion: 4.13
SMB Protokoll min: 3.0

Freigabe:

[global]
workgroup = steam
security = user
map to guest = Bad Password
interfaces = 127.0.0.1 vmbr0

[steamwindows]
path = /ssd-pool/steamwindows
writable = yes
comment = smb share
printable = no
force directory mode = 777
force user = steam
force create mode = 777
valid users = steam

Habe nun einen lokalen Benutzer "steam" auf der Maschine mit nem Passwort angelegt. Damit kommt der Server 2022 ganz normal ran. Thema1 gelöst, Thema2 geschaffen...

Nun kommt der lokale Windows10 nicht mehr ran. Zum Ersten hab ich dann bei meinen Tests bemerkt das die Vertrauensstellung zwischen der Domäne und der lokalen Arbeitsstation nicht richtig hergestellt werden kann. Also Rechner raus und wieder rein in die Domäne. Dieser Fehler ist nun weg.

Wenn ich nun versuche mit meinem Benutzer (ist auch Domänenadmin) mich mit dem Laufwerk zu verbinden kommt folgende Fehlermeldung:

Dieser Netzwerkordner ist zurzeit unter Verwendung eines anderen Namens und Kennwortes verbunden. Trennen Sie zuerst jede bestehende Verbindung auf dieser Netzwerkfreigabe, um unter Verwendung eines anderen Namens und Kennwortes verbunden zu werden.


Melde ich mich mit einem normalen Domänen Benutzer an (war noch nie angemeldet, frisches Profil), kommt diese Meldung nicht, es tut einfach so als wenn der Benutzer oder das Passwort falsch wäre.

Was funktioniert? Tja, melde ich mich mit einem lokalen Benutzer an der Maschine an, kann ich die oben genannte Freigabe auch einbinden. Versteht das wer?

Nächsten Schritte: Ich installiere mir ein virtuelles Windows10 und 11. Mal sehen wie frisch installierte Systeme reagieren. Immerhin tut ja der Server 2022 auch normal mit den Benutzern.

[Stef4n]

So ganz kann ich dein Problem noch nicht nachvollziehen, was mir jedoch dazu noch einfällt:

Wenn diese Meldung kommt "Dieser Netzwerkordner ist zurzeit unter Verwendung eines anderen Namens und Kennwortes verbunden..." kannst du diese Verbindung über die CMD trennen. Dort kannst du mal "net use" eingeben und siehst welche Verbindungen grade bestehen. mit "net use /D \\<SERVER>\steamwindows" kannst du diese dann trennen.

[ricky007]

Hallo Leute,

nun funktioniert es. Tatsächlich störte eine zweite Freigabe auf dem gleichen Server (GPO). Diese wird nämlich auch ohne Auth auf den Clients eingehängt. Und die funktionierte auch seltsamer weise immer. Jedenfalls als ich diese trennte, konnte ich auch die anderen einhängen. Nachdem das nun in dieser Reihenfolge eingehängt wird, gehts auch ganz normal. Strange.