Die Belege aus der Quelle trennen die Serverberechtigung eindeutig vom Android-Clientpfad. Dem neuen Mitglied wurde ausdrücklich der Zugriff Lesen & Schreiben gewährt, und derselbe freigegebene Ordner funktionierte von einem Computer aus. Der Android-ZimaClient meldete auf zwei Smartphones auch nach einer Neuinstallation der App weiterhin Zugriff verweigert.
Das beweist keinen bestimmten ZimaClient-Fehler, da kein IceWhale-Mitarbeiter den Thread diagnostiziert hat. Es bedeutet jedoch, dass „Sie haben vergessen, dem Mitglied Zugriff zu gewähren“ eine unvollständige Erklärung ist. Das aktuelle ZimaOS unterstützt offiziell ordnerbezogene Berechtigungen pro Benutzer. Daher sollte eine aktuelle Reproduktion dieselben Zugangsdaten über ZimaClient und direkt über SMB vergleichen, bevor Server-ACLs geändert werden.
Zuerst die ACL der serverseitigen Freigabe bestätigen
Die aktuelle IceWhale-Anleitung für Samba mit mehreren Benutzern sieht vor, dass der Administrator ein Mitglied dem freigegebenen Ordner zuweist und Lesen oder Lesen & Schreiben auswählt.
Verwenden Sie den aktuellen ZimaOS-Ablauf für Mitgliederfreigaben.
Der PC-Test zeigt, dass die Zugangsdaten des Mitglieds funktionieren können
Der ursprüngliche Verfasser sagte, dass der freigegebene Ordner von einem Computer aus zugänglich war. Das ist der nützlichste Isolierungstest in diesem Thread, da er zeigt, dass Benutzer, Konto und Freigabe zumindest über einen Clientpfad funktionieren können.
Fehler auf zwei Android-Smartphones machen eine einzelne beschädigte App-Installation weniger wahrscheinlich
Der Benutzer installierte ZimaClient neu und testete außerdem ein anderes Smartphone. Beide meldeten weiterhin Zugriff verweigert. Dadurch wird eine beschädigte Cache-Datei auf einem einzelnen Gerät weniger wahrscheinlich, auch wenn dadurch die eigentliche mobile Authentifizierungsstörung nicht identifiziert wird.
Direktes SMB unter Android testen
Eine Antwort aus der Community schlug vor, denselben Benutzernamen und dasselbe Passwort mit einem gewöhnlichen Android-SMB-Client zu testen. Wenn direktes SMB funktioniert, während ZimaClient fehlschlägt, deutet die Beweislage noch stärker auf die ZimaClient- oder Sitzungsebene statt auf Samba-ACLs hin.
Wenn beide fehlschlagen, überprüfen Sie die genauen SMB-Zugangsdaten, die Schreibweise des Benutzernamens, Sonderzeichen und den Kontostatus auf dem Server.
Die bestehende ZimaClient-Sitzung vollständig beenden
Änderungen an den Mitgliederberechtigungen werden möglicherweise nicht sofort in einer bereits authentifizierten Client-Sitzung übernommen. Melden Sie sich ab, entfernen Sie gegebenenfalls das gespeicherte Gerät bzw. die gespeicherte Sitzung, stellen Sie die Verbindung erneut her und testen Sie dieselbe Freigabe noch einmal.
Mit aktuellem ZimaOS und ZimaClient erneut testen
Die Quelle verwendete ZimaOS 1.6.1. Das aktuelle ZimaOS und die mobilen Clients wurden inzwischen geändert. Die aktuelle ZimaOS-Dokumentation bestätigt, dass Berechtigungen an ZimaOS-Konten gebunden sind und ZimaClient lokalen bzw. Remotezugriff bietet.
Die späteren Abbrüche der mobilen Verbindung waren ein separates Symptom
Der ursprüngliche Verfasser sagte später, dass die Telefonsicherung funktionierte, die mobile Verbindung jedoch häufig abbrach. Der Thread stellte nicht fest, ob dies dasselbe Berechtigungsproblem, ein Netzwerk-/P2P-Problem oder eine andere Regression des Clients war.
Behandeln Sie „Zugriff verweigert“ und „Verbindung verloren“ als separate Testfälle, sofern die Protokolle keine gemeinsame Ursache erkennen lassen.
FAQ zum Android-Zugriff von Mitgliedern
Waren die Mitgliederberechtigungen in der Quelle sichtbar konfiguriert?
Ja. Die Screenshots zeigten das Mitglied und den Ordner mit Lese- und Schreibzugriff.
Funktionierte der Ordner von einem Computer aus?
Ja. Deshalb deutet die Beweislage aus der Quelle von einem grundlegenden Fehler in der Freigabe-ACL weg.
Bestätigte der Thread eine Behebung durch IceWhale?
Nein. Der Thread endete, während das Android-Problem noch ungelöst war.
