En ny ZimaOS-användare kunde kopiera filer till en Samba-resurs från Utforskaren i Windows endast när det oskyddade gästavkontot hade lagts till. När gäståtkomsten togs bort meddelade Windows att resurserna inte gick att komma åt och visade inte någon ny fråga efter användarnamn och lösenord.
Problemet löstes utan att gäståtkomsten behövde vara aktiverad. Zima-teammedlemmen Giorgio bad användaren ta bort alla autentiseringsuppgifter som sparats av Windows och köra communityskriptet för Samba-anslutning igen. Författaren bekräftade att detta rensade konflikten och återställde åtkomsten.
Den ursprungliga konfigurationen av ZimaOS och Windows
Användaren hade installerat ZimaOS 1.4.1 på ett ASUS Prime N100I-D D4-system. En Crucial 500 GB M.2-SSD innehöll operativsystemet, medan en enda Seagate-hårddisk på 1 TB exponerades som en delad enhet via ZimaOS webbgränssnitt.
När gästanvändaren var aktiverad fungerade det att klistra in resursens URL från Manage Share i Utforskaren i Windows. Det förvirrande var att även en annan lösenordsskyddad resurs verkade vara åtkomlig i det läget, trots att gästanvändaren inte var angiven för den.
Varför de första försöken med autentiseringsuppgifter inte hjälpte
Författaren misstänkte ett problem med autentiseringsuppgifterna och lade manuellt till en post i Windows Autentiseringshanteraren. De följde även ZimaOS hjälpguide för SMB och communityns kommandoradsguide för anslutning. Skriptet frågade efter autentiseringsuppgifter, men även när det förväntade ZimaOS-användarnamnet och lösenordet angavs öppnades resursen först inte.
En potentiellt relevant detalj var att samma server och IP-adress tidigare hade körts med TrueNAS. Tråden bevisade inte att den gamla installationen orsakade konflikten, men Windows hade flera sparade webb- och Windows-autentiseringsuppgifter när problemet diagnostiserades.
Den bekräftade lösningen: Ta först bort alla sparade autentiseringsuppgifter
Giorgios instruktioner var att ta bort alla sparade autentiseringsuppgifter från Windows Kontrollpanelen, skapa en resurs på nytt vid behov och sedan upprepa kommandoradsguiden för ZimaOS Samba-anslutning. Författaren tog bort både webbaserade och Windows-autentiseringsuppgifter, körde batchfilen från guiden igen och bekräftade att åtkomsten till den skyddade resursen därefter fungerade.
Resultatet är viktigt eftersom aktivering av gäståtkomst i det här fallet bara var en tillfällig lösning. Den fungerande metoden var att få Windows att glömma sitt motstridiga autentiseringstillstånd innan en ny autentisering genomfördes.
Så här såg Zima Client-skärmarna ut
En annan communitymedlem delade de förväntade skärmbilderna från Zima Client och Windows 11 vid en fungerande konfiguration med en mappad enhet. Dessa skärmbilder var inte lösningen på författarens autentiseringskonflikt, men de gjorde det lättare att skilja den nedladdningsbara klienten från den separata kommandoradsguiden.
Vanliga frågor
Behövde användaren behålla gäståtkomsten aktiverad?
Nej. Gäståtkomst gjorde resurserna tillfälligt åtkomliga, men den bekräftade lösningen var att ta bort alla sparade Windows-autentiseringsuppgifter och återansluta med det skyddade kontot.
Löste det problemet att manuellt lägga till en autentiseringsuppgift?
Nej. Författaren hade redan försökt lägga till autentiseringsuppgifter manuellt. Det lyckade försöket kom först efter att alla sparade webb- och Windows-autentiseringsuppgifter hade tagits bort och anslutningsskriptet körts igen.
