Un nuovo utente di ZimaOS riusciva a copiare file in una condivisione Samba da Esplora file di Windows solo quando veniva aggiunto l'account guest non protetto. Una volta rimosso l'accesso guest, Windows dichiarava le condivisioni inaccessibili e non mostrava una nuova richiesta di nome utente e password.
Il caso è stato risolto senza lasciare abilitato l'accesso guest. Il membro del team Zima Giorgio ha chiesto all'utente di eliminare tutte le credenziali salvate da Windows e di eseguire nuovamente lo script della community per la connessione Samba. L'autore ha confermato che questa operazione ha eliminato il conflitto e ripristinato l'accesso.
La configurazione originale di ZimaOS e Windows
L'utente aveva installato ZimaOS 1.4.1 su un sistema ASUS Prime N100I-D D4. Un SSD M.2 Crucial da 500 GB conteneva il sistema operativo, mentre un singolo disco rigido Seagate da 1 TB era stato esposto come unità condivisa tramite l'interfaccia web di ZimaOS.
Con l'utente guest abilitato, incollare in Esplora file di Windows l'URL della condivisione ottenuto da Gestisci condivisione funzionava. L'aspetto confuso era che, in quello stato, risultava raggiungibile anche un'altra condivisione protetta da password, sebbene per essa guest non fosse elencato.
Perché i primi tentativi con le credenziali non hanno funzionato
L'autore sospettava un problema con le credenziali e aveva aggiunto manualmente una voce in Gestione credenziali di Windows. Aveva inoltre seguito la pagina di assistenza SMB di ZimaOS e il tutorial della community per la connessione dalla riga di comando. Lo script richiedeva le credenziali, ma l'inserimento del nome utente e della password ZimaOS previsti inizialmente non consentiva comunque di aprire la condivisione.
Un dettaglio potenzialmente rilevante era che lo stesso server e indirizzo IP erano stati precedentemente utilizzati con TrueNAS. La discussione non ha dimostrato che la vecchia installazione avesse causato il conflitto, ma al momento della diagnosi Windows conteneva diverse credenziali Web e Windows salvate.
La soluzione confermata: rimuovere prima tutte le credenziali salvate
La procedura indicata da Giorgio consisteva nel rimuovere tutte le credenziali salvate dal Pannello di controllo di Windows, ricreare una condivisione se necessario e quindi ripetere il tutorial ZimaOS per la connessione alle condivisioni Samba dalla riga di comando. L'autore ha eliminato sia le credenziali Web sia quelle di Windows, ha rieseguito il file batch del tutorial e ha confermato che l'accesso alla condivisione protetta funzionava finalmente.
Il risultato è importante perché, in questo caso, abilitare guest era solo una soluzione temporanea. La procedura efficace consisteva nel fare dimenticare a Windows lo stato conflittuale delle credenziali prima di autenticarsi nuovamente.
Come apparivano le schermate di Zima Client
Un altro membro della community ha condiviso le schermate previste di Zima Client e Windows 11 relative a una configurazione funzionante con unità mappata. Questi screenshot non costituivano la soluzione al conflitto delle credenziali dell'autore, ma aiutavano a distinguere il client scaricabile dal tutorial separato per la riga di comando.
FAQ
Questo utente doveva mantenere abilitato l'accesso guest?
No. L'accesso guest rendeva temporaneamente raggiungibili le condivisioni, ma la soluzione confermata consisteva nel rimuovere tutte le credenziali di Windows salvate e riconnettersi utilizzando l'account protetto.
L'aggiunta manuale di una credenziale ha risolto il problema?
No. L'autore aveva già provato ad aggiungere manualmente le credenziali. Il tentativo riuscito è avvenuto solo dopo aver eliminato tutte le credenziali Web e Windows salvate e aver rieseguito lo script di connessione.
