Pourquoi Windows peut lire un partage ZimaOS sans pouvoir y écrire
Le cas présenté par la communauté indique un problème d’authentification plutôt qu’une défaillance du stockage. Android disposait d’un accès en lecture et en écriture, tandis que l’Explorateur de fichiers Windows accédait en réalité au partage en tant qu’invité. L’accès invité peut permettre de parcourir le contenu ou d’accéder aux fichiers en lecture seule, mais les opérations d’écriture nécessitent les identifiants d’un membre ZimaOS disposant d’une autorisation de lecture et d’écriture sur ce partage.
Le guide actuel de la boutique consacré à l’accès SMB authentifié à ZimaOS explique le même modèle d’autorisations basé sur les membres pour un autre système d’exploitation de bureau. Pour une vue d’ensemble des échanges de fichiers entre appareils, consultez le guide du partage de fichiers NAS.
Vérifiez d’abord les autorisations du partage ZimaOS
- Ouvrez les paramètres de partage du dossier cible dans ZimaOS.
- Vérifiez que l’utilisateur ou le membre souhaité est bien affecté au partage.
- Définissez pour ce membre une autorisation de lecture et d’écriture plutôt que de lecture seule.
- Laissez l’accès invité désactivé si l’accès anonyme n’est pas nécessaire.
Cette vérification permet de distinguer l’autorisation côté serveur de la mise en cache des identifiants Windows. Si le membre ne dispose pas de l’autorisation d’écriture, la modification des paramètres Windows ne la créera pas.
Supprimez l’ancienne connexion invitée dans Windows
Windows peut réutiliser une session SMB existante ou des identifiants enregistrés, ce qui peut amener l’Explorateur de fichiers à se reconnecter sans demander le compte approprié. Microsoft documente les identifiants Windows et l’authentification réseau via le Gestionnaire d’identifiants et les outils SMB. Consultez la documentation de Microsoft sur le Gestionnaire d’identifiants avant de supprimer des entrées dont vous avez encore besoin.
Après avoir supprimé la connexion obsolète, reconnectez-vous au partage ZimaOS et fournissez le nom d’utilisateur et le mot de passe du membre ZimaOS. Microsoft documente également le fonctionnement de SMB pour les clients Windows dans la présentation SMB de Microsoft.
Montez explicitement le partage
Dans l’Explorateur de fichiers, utilisez le chemin réseau fourni par ZimaOS ou mappez le partage comme lecteur réseau. Si Windows l’ouvre toujours en tant qu’invité, déconnectez d’abord les lecteurs réseau existants, puis reconnectez-vous avec les identifiants du membre. Évitez d’enregistrer les mots de passe dans des scripts ou des captures d’écran.
Le rôle de Zima Client
Dans la discussion d’origine, l’accès en écriture est apparu après que Zima Client a remonté le lecteur, ce qui suggère que le client a rétabli un chemin authentifié. Il s’agit d’une explication plausible, mais elle n’a pas été démontrée dans la discussion. Si vous utilisez Zima Client, vérifiez le partage monté après la connexion et contrôlez tout de même les autorisations sous-jacentes du partage au lieu de supposer que le montage suffit à accorder l’accès en écriture.
La page actuelle sur la connectivité de Zima Client explique comment les appareils de bureau et mobiles se connectent à ZimaOS.
FAQ
Pourquoi Android peut-il écrire alors que Windows ne le peut pas ?
Les deux clients peuvent s’authentifier différemment. Un gestionnaire de fichiers mobile peut conserver des identifiants de membre valides, tandis que Windows réutilise une session invitée.
Dois-je activer l’accès invité pour résoudre le problème ?
Non, si vous avez besoin d’un accès en écriture contrôlé. Utilisez un compte membre avec une autorisation explicite de lecture et d’écriture.
Que faire si le partage redevient soudainement accessible en écriture ?
Vérifiez quelle identité Windows utilise et si Zima Client a rétabli le montage. Notez la configuration fonctionnelle afin de pouvoir reproduire le problème s’il réapparaît.
