元の証拠は、サーバー権限とAndroidクライアント側の経路を明確に分けています。新しいメンバーには明示的に読み取りと書き込みアクセスが付与されており、同じ共有フォルダーはコンピューターから正常に使用できました。それでもAndroid版ZimaClientでは、アプリを再インストールした後も2台のスマートフォンでPermission Deniedが返されました。
このことだけで特定のZimaClientのバグだと証明できるわけではありません。スレッド内でIceWhaleのスタッフが診断を行っていないためです。ただし、「メンバーにアクセス権を付与し忘れた」という説明だけでは不十分です。現在のZimaOSはユーザーごとのフォルダー権限を正式にサポートしているため、現行環境で再現テストを行う場合は、サーバーのACLを変更する前に、ZimaClientと直接SMB接続で同じ認証情報を比較すべきです。
まずサーバー側の共有ACLを確認する
現在のIceWhaleのマルチユーザーSambaガイダンスでは、管理者が共有フォルダーにメンバーを割り当て、読み取りまたは読み取りと書き込みを選択することが想定されています。
現在のZimaOSのメンバー共有ワークフローを使用してください。
PCテストでメンバーの認証情報が機能することを確認できる
元の投稿者は、共有フォルダーにコンピューターからアクセスできたと述べています。これはスレッドで最も有用な切り分けテストです。少なくとも1つのクライアント経路では、ユーザー、アカウント、共有が機能することを示しているからです。
2台のAndroidスマートフォンで失敗したため、1台だけのアプリインストール破損の可能性は低い
ユーザーはZimaClientを再インストールし、別のスマートフォンでもテストしました。それでも両方でPermission Deniedが返されました。これは、1台の端末だけでキャッシュが破損している可能性を低くしますが、実際のモバイル認証の失敗原因を特定するものではありません。
Androidから直接SMBをテストする
コミュニティの返信では、通常のAndroid SMBクライアントを使い、同じユーザー名とパスワードでテストすることが提案されていました。直接SMBでは成功する一方でZimaClientでは失敗する場合、SambaのACLよりもZimaClientまたはセッション層に原因がある可能性がさらに高くなります。
両方で失敗する場合は、SMBの認証情報、ユーザー名の形式、特殊文字、サーバー側のアカウント状態を正確に確認してください。
既存のZimaClientセッションを完全に終了する
メンバー権限を変更しても、すでに認証済みのクライアントセッションにはすぐ反映されない場合があります。サインアウトし、現在のクライアントで必要であれば保存済みのデバイスやセッションを削除してから再接続し、同じ共有を再テストしてください。
現在のZimaOSとZimaClientで再テストする
元の環境はZimaOS 1.6.1でした。現在のZimaOSとモバイルクライアントは変更されています。現在のZimaOSドキュメントでは、権限がZimaOSアカウントに紐付けられていること、またZimaClientがローカルおよびリモートアクセスを提供することが確認されています。
後から発生したモバイル接続の切断は別の症状だった
投稿者は後に、スマートフォンからのバックアップは機能するものの、モバイル接続が頻繁に切断されると述べました。スレッドでは、それが同じ権限問題なのか、ネットワークやP2Pの問題なのか、別のクライアント回帰なのかは明らかになっていません。
ログで共通の原因が示されない限り、「Permission Denied」と「接続が失われる」を別々のテストケースとして扱ってください。
Androidでのメンバーアクセスに関するFAQ
元の環境ではメンバー権限が目視で設定されていましたか？
はい。スクリーンショットには、メンバーとフォルダーに読み取りと書き込みアクセスが設定されていることが示されています。
コンピューターからフォルダーを使用できましたか？
はい。そのため、元の証拠は基本的な共有ACLの設定ミスではない可能性を示しています。
スレッド内でIceWhaleによる修正は確認されましたか？
いいえ。Androidでの問題が未解決のまま終了しています。
