Ein neuer ZimaOS-Benutzer konnte Dateien aus dem Windows-Explorer nur dann auf eine Samba-Freigabe kopieren, wenn das ungeschützte Gastkonto hinzugefügt war. Nachdem der Gastzugriff entfernt worden war, erklärte Windows die Freigaben für nicht erreichbar und zeigte keine neue Aufforderung zur Eingabe von Benutzername und Passwort an.
Der Fall wurde gelöst, ohne den Gastzugriff aktiviert zu lassen. Das Zima-Teammitglied Giorgio bat den Benutzer, alle von Windows gespeicherten Anmeldeinformationen zu löschen und das Community-Skript zur Samba-Verbindung erneut auszuführen. Der Autor bestätigte, dass dadurch der Konflikt beseitigt und der Zugriff wiederhergestellt wurde.
Die ursprüngliche ZimaOS- und Windows-Konfiguration
Der Benutzer hatte ZimaOS 1.4.1 auf einem ASUS Prime N100I-D D4-System installiert. Eine Crucial M.2-SSD mit 500 GB enthielt das Betriebssystem, während eine einzelne Seagate-Festplatte mit 1 TB über die Weboberfläche von ZimaOS als freigegebenes Laufwerk bereitgestellt wurde.
Bei aktiviertem Gastbenutzer funktionierte das Einfügen der Freigabe-URL aus „Freigabe verwalten“ in den Windows-Explorer. Verwirrend war, dass in diesem Zustand auch eine andere passwortgeschützte Freigabe erreichbar zu sein schien, obwohl der Gastbenutzer dort nicht aufgeführt war.
Warum die ersten Anmeldeversuche nicht halfen
Der Autor vermutete ein Problem mit den Anmeldeinformationen und fügte manuell einen Eintrag im Windows-Anmeldeinformationsmanager hinzu. Außerdem folgte er der ZimaOS-Hilfeseite für SMB und der Community-Anleitung zur Verbindung über die Befehlszeile. Das Skript forderte zur Eingabe von Anmeldeinformationen auf, doch selbst die Eingabe des erwarteten ZimaOS-Benutzernamens und -passworts öffnete die Freigabe zunächst nicht.
Ein möglicherweise relevanter Umstand war, dass zuvor TrueNAS auf demselben Server und derselben IP-Adresse betrieben worden war. Der Thread belegte nicht, dass die alte Installation den Konflikt verursacht hatte. Zum Zeitpunkt der Diagnose hatte Windows jedoch mehrere gespeicherte Web- und Windows-Anmeldeinformationen.
Die bestätigte Lösung: Zuerst alle gespeicherten Anmeldeinformationen entfernen
Giorgios Vorgehensweise bestand darin, alle gespeicherten Anmeldeinformationen über die Windows-Systemsteuerung zu entfernen, bei Bedarf eine Freigabe neu zu erstellen und anschließend die Anleitung zur Samba-Verbindung mit ZimaOS über die Befehlszeile erneut auszuführen. Der Autor löschte sowohl Webanmeldeinformationen als auch Windows-Anmeldeinformationen, führte die Batchdatei aus dieser Anleitung erneut aus und bestätigte, dass der Zugriff auf die geschützte Freigabe schließlich funktionierte.
Das Ergebnis ist wichtig, weil die Aktivierung des Gastzugriffs in diesem Fall nur eine Umgehungslösung war. Der erfolgreiche Weg bestand darin, Windows vor der erneuten Authentifizierung seinen widersprüchlichen Anmeldeinformationsstatus vergessen zu lassen.
So sahen die Bildschirme des Zima Client aus
Ein anderes Community-Mitglied teilte die erwarteten Ansichten des Zima Client und von Windows 11 aus einer funktionierenden Einrichtung mit verbundenem Netzlaufwerk. Diese Screenshots waren nicht die Lösung für den Anmeldeinformationskonflikt des Autors, halfen aber dabei, den herunterladbaren Client von der separaten Anleitung zur Verbindung über die Befehlszeile zu unterscheiden.
FAQ
Musste dieser Benutzer den Gastzugriff aktiviert lassen?
Nein. Der Gastzugriff machte die Freigaben vorübergehend erreichbar, aber die bestätigte Lösung bestand darin, alle gespeicherten Windows-Anmeldeinformationen zu entfernen und die Verbindung mit dem geschützten Konto wiederherzustellen.
Hat das manuelle Hinzufügen einer einzelnen Anmeldeinformation das Problem gelöst?
Nein. Der Autor hatte bereits versucht, Anmeldeinformationen manuell hinzuzufügen. Der erfolgreiche Versuch gelang erst, nachdem alle gespeicherten Web- und Windows-Anmeldeinformationen gelöscht und anschließend das Verbindungsskript erneut ausgeführt worden waren.
