Un nouvel utilisateur de ZimaOS ne pouvait copier des fichiers vers un partage Samba depuis l’Explorateur de fichiers Windows qu’après avoir ajouté le compte invité non protégé. Une fois l’accès invité supprimé, Windows déclarait les partages inaccessibles et n’affichait pas de nouvelle demande de nom d’utilisateur et de mot de passe.
Le problème a été résolu sans laisser l’accès invité activé. Giorgio, membre de l’équipe Zima, a demandé à l’utilisateur de supprimer tous les identifiants enregistrés par Windows, puis de relancer le script communautaire de connexion Samba. L’auteur a confirmé que cette opération avait supprimé le conflit et rétabli l’accès.
Configuration initiale de ZimaOS et de Windows
L’utilisateur avait installé ZimaOS 1.4.1 sur un système ASUS Prime N100I-D D4. Un SSD M.2 Crucial de 500 Go hébergeait le système d’exploitation, tandis qu’un unique disque dur Seagate de 1 To était exposé comme lecteur partagé via l’interface web de ZimaOS.
Lorsque l’utilisateur invité était activé, le collage de l’URL du partage depuis Manage Share dans l’Explorateur de fichiers Windows fonctionnait. La partie déroutante était qu’un autre partage protégé par mot de passe semblait également accessible dans cet état, même si l’utilisateur invité n’y était pas indiqué.
Pourquoi les premières tentatives d’authentification n’ont pas fonctionné
L’auteur soupçonnait un problème d’identifiants et a ajouté manuellement une entrée dans le Gestionnaire d’identifiants Windows. Il a également suivi la page d’aide SMB de ZimaOS et le tutoriel communautaire de connexion en ligne de commande. Le script demandait les identifiants, mais la saisie du nom d’utilisateur et du mot de passe ZimaOS attendus n’a pas permis d’ouvrir le partage dans un premier temps.
Un détail potentiellement pertinent était que le même serveur et la même adresse IP avaient auparavant exécuté TrueNAS. La discussion n’a pas prouvé que l’ancienne installation était à l’origine du conflit, mais Windows comptait plusieurs identifiants web et Windows enregistrés lorsque le problème a été diagnostiqué.
La solution confirmée : supprimer d’abord tous les identifiants enregistrés
La procédure proposée par Giorgio consistait à supprimer tous les identifiants enregistrés depuis le Panneau de configuration Windows, à recréer un partage si nécessaire, puis à relancer le tutoriel de connexion Samba ZimaOS en ligne de commande. L’auteur a supprimé les identifiants web et les identifiants Windows, relancé le fichier de commandes fourni dans ce tutoriel, puis confirmé que l’accès au partage protégé fonctionnait enfin.
Ce résultat est important, car l’activation de l’accès invité n’était qu’une solution de contournement dans ce cas. La méthode efficace consistait à faire oublier à Windows ses identifiants en conflit avant de s’authentifier à nouveau.
À quoi ressemblaient les écrans du client Zima
Un autre membre de la communauté a partagé les écrans attendus de Zima Client et de Windows 11 dans le cadre d’une configuration fonctionnelle avec lecteur réseau mappé. Ces captures d’écran ne correspondaient pas à la solution du conflit d’identifiants de l’auteur, mais elles ont permis de distinguer le client téléchargeable du tutoriel CLI distinct.
FAQ
Cet utilisateur devait-il conserver l’accès invité activé ?
Non. L’accès invité rendait temporairement les partages accessibles, mais la résolution confirmée consistait à supprimer tous les identifiants Windows enregistrés, puis à se reconnecter avec le compte protégé.
L’ajout manuel d’un identifiant a-t-il résolu le problème ?
Non. L’auteur avait déjà essayé d’ajouter manuellement des identifiants. La tentative réussie n’a fonctionné qu’après la suppression de tous les identifiants web et Windows enregistrés, puis la relance du script de connexion.
