Vérifier que les partages fantômes proviennent du serveur
Le propriétaire du ZimaCube pouvait toujours voir et monter des partages SMB vides issus de deux tentatives échouées de configuration RAID5. Les partages actuels de ZimaOS 1.2.2 pouvaient être ajoutés et supprimés normalement, mais les anciens noms restaient présents dans le sélecteur de partages réseau.
Un Mac qui ne s’était jamais connecté au ZimaCube affichait les mêmes anciens noms. Ce contrôle a écarté l’hypothèse d’un cache limité à un seul client et a situé l’état obsolète du côté du serveur.
Répétez cette vérification sans risque avant de modifier le serveur : comparez la liste d’un nouveau client ou d’un profil vierge avec les partages actifs affichés dans Fichiers de ZimaOS. Notez quelles entrées sont réelles et lesquelles se montent comme des partages vides.
Ne reconstruisez pas le RAID fonctionnel pour supprimer les noms de partages
L’équipe a déclaré que son principe de réparation consistait à éviter de forcer les utilisateurs à reconstruire ou à recharger les données RAID, sauf nécessité absolue. Elle a ensuite confirmé que le problème de partage n’affecterait pas les données RAID existantes.
Cela sépare l’intégrité du stockage du nettoyage de la liste des partages. Vérifiez d’abord l’état de la grappe actuelle et des partages réels. Si le RAID est sain et que les données restent accessibles, les noms fantômes ne prouvent pas que la grappe doit être recréée.
Si la grappe elle-même est dégradée ou absente, arrêtez-vous et traitez cela comme un incident de récupération distinct. Ne combinez pas une réparation du stockage avec un nettoyage SMB, car vous ne pourriez plus déterminer quelle modification a affecté quel problème.
L’équipe a confirmé un bogue de gestion des partages
Un membre de l’équipe ZimaOS a confirmé que les opérations sur les fichiers et le stockage n’étaient alors pas associées au nettoyage des partages. Un autre utilisateur a signalé un symptôme connexe : renommer ou supprimer un dossier partagé laissait son ancien nom SMB actif.
Le problème initial est apparu après que ZimaOS 1.2 n’a pas conservé la configuration RAID lors des cycles de mise hors tension. La mise à jour vers 1.2.1 et 1.2.2 a cessé le problème de persistance du RAID, mais les anciens enregistrements de partage sont restés.
ZimaOS 1.2.3 ne les a pas supprimés. L’équipe a indiqué que le correctif était prévu pour la version 1.2.4 et a proposé une assistance à distance auparavant, mais le sujet ne contient aucun message ultérieur confirmant que la version 1.2.4 a supprimé les entrées de l’auteur. Conservez cette limite de version.
Évitez de modifier manuellement les fichiers Samba générés
L’auteur a trouvé des définitions obsolètes dans /etc/samba/smb.casa.conf. Modifier, supprimer ou remplacer ce fichier n’a pas persisté après le redémarrage, et la liste réseau contenait parfois davantage de noms que le fichier lui-même.
Ce comportement indique qu’un autre composant régénérait ou fournissait l’état des partages. Des modifications manuelles répétées risquent de créer un écart avec la gestion de ZimaOS sans produire de réparation durable.
Restaurez toute modification expérimentale, laissez le RAID actif intact et utilisez l’interface prise en charge, la procédure de mise à jour ou le processus d’assistance à distance. La récupération doit être validée depuis un nouveau client après un redémarrage, et pas uniquement par l’inspection d’un seul fichier de configuration.
Escalader le problème avec un inventaire reproductible des partages
Si une mise à jour prise en charge ne supprime pas les entrées fantômes, recueillez la version de ZimaOS, la liste des partages dans Fichiers, le sélecteur de partages du client et les noms qui se montent à vide. Indiquez que la même liste apparaît sur un nouveau client.
Demandez une correction de l’état des partages sans autoriser une reconstruction du RAID, sauf si des éléments indépendants liés au stockage l’exigent. L’équipe a proposé une assistance à distance précisément pour supprimer les partages fantômes avant sa mise à jour prévue.
Après la correction, redémarrez une fois, reconnectez-vous depuis un client existant et un nouveau client, puis vérifiez que seuls les partages actifs apparaissent et ouvrent les chemins attendus. Ce test complet confirme la récupération.
FAQ
Les partages SMB fantômes sont-ils uniquement dus à un problème de cache de macOS ?
Pas dans ce cas. Un Mac qui ne s’était jamais connecté auparavant au ZimaCube affichait les mêmes entrées.
ZimaOS 1.2.3 a-t-il supprimé les anciens partages ?
Non. L’auteur a explicitement indiqué que la version 1.2.3 ne les avait pas corrigés.
Le sujet a-t-il confirmé que ZimaOS 1.2.4 corrigeait le bogue ?
L’équipe avait prévu le correctif pour la version 1.2.4, mais le fil ne contient aucune validation finale par l’utilisateur.
