Een nieuwe ZimaOS-gebruiker kon alleen bestanden naar een Samba-share kopiëren vanuit Windows Verkenner wanneer het onbeveiligde gastaccount was toegevoegd. Zodra gasttoegang werd verwijderd, verklaarde Windows de shares ontoegankelijk en verscheen er geen nieuwe vraag om een gebruikersnaam en wachtwoord.
De kwestie werd opgelost zonder gasttoegang ingeschakeld te laten. Zima-teamlid Giorgio vroeg de gebruiker alle door Windows opgeslagen aanmeldgegevens te verwijderen en het communityscript voor de Samba-verbinding opnieuw uit te voeren. De auteur bevestigde dat dit het conflict oploste en de toegang herstelde.
De oorspronkelijke ZimaOS- en Windows-installatie
De gebruiker had ZimaOS 1.4.1 geïnstalleerd op een ASUS Prime N100I-D D4-systeem. Een Crucial M.2-SSD van 500 GB bevatte het besturingssysteem, terwijl één Seagate-harde schijf van 1 TB via de webinterface van ZimaOS als gedeelde schijf beschikbaar was gesteld.
Met de gastgebruiker ingeschakeld werkte het plakken van de share-URL uit Share beheren in Windows Verkenner. Het verwarrende was dat een andere met een wachtwoord beveiligde share in die toestand ook bereikbaar leek, hoewel gast daarvoor niet als gebruiker was opgegeven.
Waarom de eerste pogingen met aanmeldgegevens niet hielpen
De auteur vermoedde dat er een probleem met de aanmeldgegevens was en voegde handmatig een item toe in Windows Referentiebeheer. Ook volgde de auteur de SMB-helppagina van ZimaOS en de communityhandleiding voor verbinding via de opdrachtregel. Het script vroeg om aanmeldgegevens, maar het invoeren van de verwachte ZimaOS-gebruikersnaam en het wachtwoord opende de share aanvankelijk nog steeds niet.
Een mogelijk relevant detail was dat dezelfde server en hetzelfde IP-adres eerder TrueNAS hadden uitgevoerd. De thread bewees niet dat de oude installatie het conflict veroorzaakte, maar Windows had op het moment van de diagnose wel meerdere opgeslagen web- en Windows-aanmeldgegevens.
De bevestigde oplossing: verwijder eerst alle opgeslagen aanmeldgegevens
Giorgio's stappenplan was om alle opgeslagen aanmeldgegevens uit het Configuratiescherm van Windows te verwijderen, indien nodig een share opnieuw aan te maken en vervolgens de handleiding voor verbinding met ZimaOS Samba via de opdrachtregel opnieuw te volgen. De auteur verwijderde zowel de webreferenties als de Windows-referenties, voerde het batchbestand uit die handleiding opnieuw uit en bevestigde dat toegang tot de beveiligde share uiteindelijk werkte.
Het resultaat is belangrijk, omdat het inschakelen van gasttoegang in dit geval slechts een tijdelijke oplossing was. De succesvolle aanpak was om Windows de conflicterende aanmeldstatus te laten vergeten voordat er opnieuw werd geauthenticeerd.
Hoe de schermen van de Zima Client eruitzagen
Een ander communitylid deelde de verwachte schermen van de Zima Client en Windows 11 uit een werkende configuratie met een toegewezen netwerkstation. Deze schermafbeeldingen vormden niet de oplossing voor het aanmeldgegevensconflict van de auteur, maar hielpen wel om de downloadbare client te onderscheiden van de afzonderlijke handleiding voor verbinding via de opdrachtregel.
Veelgestelde vragen
Moest deze gebruiker gasttoegang ingeschakeld houden?
Nee. Gasttoegang maakte de shares tijdelijk bereikbaar, maar de bevestigde oplossing was om alle opgeslagen Windows-aanmeldgegevens te verwijderen en opnieuw verbinding te maken met het beveiligde account.
Lostte het handmatig toevoegen van één aanmeldgegeven het probleem op?
Nee. De auteur had al geprobeerd handmatig aanmeldgegevens toe te voegen. De succesvolle poging kwam pas nadat alle opgeslagen web- en Windows-aanmeldgegevens waren verwijderd en het verbindingsscript opnieuw was uitgevoerd.
