Les éléments disponibles distinguent clairement l’autorisation du serveur du problème lié au client Android. Le nouveau membre s’était explicitement vu accorder un accès en lecture et écriture, et le même dossier partagé fonctionnait depuis un ordinateur. ZimaClient sur Android affichait toujours Accès refusé sur deux téléphones, même après la réinstallation de l’application.
Cela ne prouve pas l’existence d’un bug précis de ZimaClient, car aucun membre du personnel d’IceWhale n’a diagnostiqué le fil. Cela signifie toutefois que l’explication « vous avez oublié d’accorder l’accès au membre » est incomplète. ZimaOS prend officiellement en charge les autorisations de dossiers par utilisateur. Une nouvelle reproduction devrait donc comparer les mêmes identifiants via ZimaClient et directement via SMB avant de modifier les ACL du serveur.
Confirmer d’abord l’ACL du partage côté serveur
Les instructions actuelles d’IceWhale concernant Samba multi-utilisateur prévoient que le gestionnaire attribue un membre au dossier partagé et choisisse Lecture ou Lecture et écriture.
Utilisez le processus actuel de gestion des partages par membres dans ZimaOS.
Le test sur PC montre que les identifiants du membre peuvent fonctionner
L’auteur d’origine a indiqué que le dossier partagé était accessible depuis un ordinateur. Il s’agit du test d’isolation le plus utile du fil, car il montre que l’utilisateur, le compte et le partage peuvent fonctionner au moins via un chemin client.
L’échec sur deux téléphones Android réduit la probabilité d’une seule installation corrompue
L’utilisateur a essayé de réinstaller ZimaClient et a également testé un autre téléphone. Les deux appareils affichaient toujours « Accès refusé ». Cela rend moins probable une corruption du cache sur un seul téléphone, sans toutefois identifier la cause réelle de l’échec de l’authentification mobile.
Tester directement SMB depuis Android
Une réponse de la communauté suggérait de tester le même nom d’utilisateur et le même mot de passe avec un client SMB Android classique. Si SMB direct fonctionne alors que ZimaClient échoue, les éléments disponibles pointeront encore davantage vers la couche ZimaClient/session plutôt que vers les ACL Samba.
Si les deux échouent, vérifiez les identifiants SMB exacts, le format du nom d’utilisateur, les caractères spéciaux et l’état du compte côté serveur.
Mettre complètement fin à la session ZimaClient existante
La modification des autorisations d’un membre peut ne pas mettre à jour immédiatement une session client déjà authentifiée. Déconnectez-vous, supprimez l’appareil ou la session enregistrée si le client actuel l’exige, reconnectez-vous, puis testez à nouveau le même partage.
Effectuer un nouveau test avec les versions actuelles de ZimaOS et ZimaClient
La source utilisait ZimaOS 1.6.1. Les versions actuelles de ZimaOS et des clients mobiles ont évolué. La documentation actuelle de ZimaOS confirme que les autorisations sont associées aux comptes ZimaOS et que ZimaClient fournit un accès local ou distant.
Les déconnexions mobiles apparues ultérieurement constituaient un symptôme distinct
L’auteur a ensuite indiqué que la sauvegarde depuis le téléphone fonctionnait, mais que la connexion mobile était fréquemment interrompue. Le fil n’a pas établi s’il s’agissait du même problème d’autorisation, d’un problème de réseau ou de P2P, ou d’une autre régression du client.
Traitez « Accès refusé » et « connexion perdue » comme deux cas de test distincts, à moins que les journaux ne révèlent une cause commune.
FAQ sur l’accès Android des membres
Les autorisations du membre étaient-elles visiblement configurées dans la source ?
Oui. Les captures d’écran montraient que le membre et le dossier disposaient d’un accès en lecture et écriture.
Le dossier fonctionnait-il depuis un ordinateur ?
Oui, ce qui explique pourquoi les éléments disponibles écartent une erreur élémentaire d’ACL du partage.
Le fil a-t-il confirmé un correctif d’IceWhale ?
Non. Il s’est terminé alors que le problème Android n’était toujours pas résolu.
