新しいZimaOSユーザーは、保護されていないゲストアカウントを追加した場合に限り、WindowsエクスプローラーからSamba共有へファイルをコピーできました。ゲストアクセスを削除すると、Windowsは共有にアクセスできないと表示しましたが、新しいユーザー名とパスワードの入力画面は表示されませんでした。
この問題は、ゲストアクセスを有効にしたままにせず解決しました。ZimaチームメンバーのGiorgioは、Windowsに保存されているすべての資格情報を削除し、コミュニティ提供のSamba接続スクリプトを再度実行するようユーザーに案内しました。投稿者は、これによって競合が解消され、アクセスが復旧したことを確認しました。
当初のZimaOSとWindowsの構成
ユーザーはASUS Prime N100I-D D4システムにZimaOS 1.4.1をインストールしていました。Crucial製500 GB M.2 SSDにオペレーティングシステムを保存し、Seagate製1 TBハードドライブ1台をZimaOSのWebインターフェースから共有ドライブとして公開していました。
ゲストユーザーを有効にすると、Windowsエクスプローラーの「共有の管理」からコピーした共有URLを貼り付けてアクセスできました。わかりにくかったのは、その状態では、ゲストユーザーが設定されていない別のパスワード保護された共有にもアクセスできるように見えたことです。
最初の資格情報の試行で解決しなかった理由
投稿者は資格情報に問題があると考え、Windowsの資格情報マネージャーにエントリを手動で追加しました。また、ZimaOSのSMBヘルプページと、コミュニティのコマンドライン接続チュートリアルにも従いました。スクリプトは資格情報の入力を求めましたが、想定していたZimaOSのユーザー名とパスワードを入力しても、当初は共有を開けませんでした。
関連している可能性がある詳細として、同じサーバーとIPアドレスで以前TrueNASを実行していたことが挙げられます。古いインストールが競合の原因だったとはスレッド内で証明されていませんが、問題を診断した時点で、WindowsにはWeb資格情報とWindows資格情報が複数保存されていました。
確認された解決策：最初に保存済みの資格情報をすべて削除する
Giorgioが案内した手順は、Windowsのコントロールパネルから保存済みの資格情報をすべて削除し、必要に応じて共有を作り直したうえで、ZimaOS Sambaコマンドライン接続チュートリアルを再度実行するというものでした。投稿者はWeb資格情報とWindows資格情報の両方を削除し、そのチュートリアルのバッチファイルを再実行したところ、保護された共有にようやくアクセスできるようになったことを確認しました。
この結果が重要なのは、このケースでゲストを有効にすることは単なる回避策にすぎなかったためです。成功した手順は、再認証する前にWindowsに競合している資格情報の状態を忘れさせることでした。
Zima Clientの画面
別のコミュニティメンバーが、正常にマッピングされたドライブ構成でのZima ClientとWindows 11の画面を共有しました。これらのスクリーンショットは、投稿者の資格情報の競合を解決した方法ではありませんが、ダウンロード可能なクライアントと別個のCLIチュートリアルを区別するのに役立ちました。
FAQ
このユーザーはゲストアクセスを有効にしたままにする必要がありましたか？
いいえ。ゲストアクセスによって一時的に共有へアクセスできるようになりましたが、確認された解決策は、Windowsに保存されているすべての資格情報を削除し、保護されたアカウントを使って再接続することでした。
資格情報を1つ手動で追加すれば問題は解決しましたか？
いいえ。投稿者はすでに資格情報の手動追加を試していました。成功したのは、保存されていたすべてのWeb資格情報とWindows資格情報を削除してから、接続スクリプトを再実行した後でした。
