WindowsではZimaOSの共有を読み取れるのに書き込めない理由
コミュニティでの事例からは、ストレージ障害ではなく認証の不一致が原因だと考えられます。Androidでは読み取りと書き込みが可能だった一方、Windowsのファイル エクスプローラーは実質的にゲストとして共有へアクセスしていました。ゲストアクセスでは参照や読み取り専用アクセスが許可される場合がありますが、書き込み操作には、その共有に対する読み取りと書き込みの権限を持つZimaOSメンバーの認証情報が必要です。
現在の認証済みZimaOS SMBアクセスに関するショップガイドでは、別のデスクトップOSにおける同じメンバーベースの権限モデルを説明しています。デバイスをまたいだ一般的な概要については、NASファイル共有ガイドをご覧ください。
まずZimaOSの共有権限を確認する
- ZimaOSで対象フォルダーの共有設定を開きます。
- 目的のユーザーまたはメンバーが共有に割り当てられていることを確認します。
- そのメンバーを読み取り専用ではなく、読み取りと書き込みに設定します。
- 匿名アクセスが不要な場合は、ゲストアクセスを無効にしておきます。
これにより、サーバー側の認可とWindowsの認証情報キャッシュを切り分けられます。メンバーに書き込み権限がなければ、Windowsの設定を変更しても権限は付与されません。
Windowsで古いゲスト接続を削除する
Windowsは既存のSMBセッションや保存済みの認証情報を再利用することがあるため、正しいアカウントを尋ねずにファイル エクスプローラーが再接続してしまう場合があります。Microsoftは、資格情報マネージャーとSMBツールを通じたWindowsの資格情報およびネットワーク認証について説明しています。まだ必要なエントリを削除する前に、Microsoftの資格情報マネージャーのドキュメントを確認してください。
古い接続を消去したら、ZimaOSのメンバーのユーザー名とパスワードを入力して、ZimaOSの共有に再接続します。Microsoftは、Microsoft SMBの概要でも、WindowsクライアントにおけるSMBの動作について説明しています。
共有を明示的に割り当てる
ファイル エクスプローラーで、ZimaOSから提供されたネットワークパスを使用するか、共有をネットワークドライブとして割り当てます。それでもWindowsがゲストとして開く場合は、既存の割り当てを先に切断し、メンバーの認証情報で再接続してください。パスワードをスクリプトやスクリーンショットに保存することは避けてください。
Zima Clientの役割
元のスレッドでは、Zima Clientがドライブを再マウントした後に書き込みアクセスが可能になったため、クライアントが認証済みの経路を復元した可能性が示されています。これは妥当な説明ですが、スレッド内で証明されたわけではありません。Zima Clientを使用する場合は、サインイン後にマウントされた共有を確認し、マウントだけで書き込み権限が付与されると考えず、基盤となる共有権限も確認してください。
現在のZima Clientの接続ページでは、デスクトップおよびモバイルデバイスをZimaOSに接続する方法を説明しています。
よくある質問
なぜAndroidでは書き込めるのに、Windowsでは書き込めないのですか？
2つのクライアントで認証方法が異なる可能性があります。モバイルのファイルマネージャーは有効なメンバーの認証情報を保持している一方、Windowsはゲストセッションを再利用している可能性があります。
この問題を解決するためにゲストアクセスを有効にすべきですか？
管理された書き込みアクセスが必要な場合は、有効にしないでください。明示的に読み取りと書き込みの権限を付与したメンバーアカウントを使用します。
共有が突然、再び書き込み可能になった場合はどうすればよいですか？
Windowsが使用しているIDと、Zima Clientがマウントを再確立したかどうかを確認します。問題が再発した場合に再現できるよう、動作した設定を記録しておきましょう。
