Ubuntu 22.04 で Azure Storage Explorer（snap 版）を v1.39 以降に更新した途端、起動しない／「password-manager-service に接続できない」エラーが出ることがあります。本記事では、snap 版で試すべき確認手順と、確実に作業を続けるための tar.gz / AppImage 版への移行手順を、現場目線で整理します。
まず結論：急いでいるなら「tar.gz / AppImage 版」が最短ルート
この手のエラーは、snap のサンドボックス制約と OS 側の鍵管理（Keyring）が噛み合わないことが原因になりやすく、環境差で解決が長引きがちです。業務で今すぐストレージに触る必要があるなら、まずは snap をやめて tar.gz / AppImage 版へ切り替えるのが現実解です。
もちろん、snap 版で直るケースもあります。そこで本記事では、「最短で復旧するための回避策」と「snap 版を直したい人向けの切り分け」を両方まとめます。
現象の整理：何が起きているのか
今回のトラブルは、だいたい次のような流れで発生します。
- Ubuntu 22.04（GNOME / Wayland または X11）上に、snap から Azure Storage Explorer v1.39.0 以降をインストール
- 起動しようとしてもアプリが立ち上がらず、ターミナルやログ上で「password-manager-service に接続できない」旨のエラーが出る
sudo snap connect storage-explorer:password-manager-service :password-manager-serviceを実行しても改善しない- snap の仕組み上、古いバージョン（例：v1.38.0）へ簡単にダウングレードできない
| 項目 | 内容 | 最初に見るポイント |
|---|---|---|
| エラーの主語 | password-manager-service（パスワード管理サービス） | snap のインターフェイス接続と、OS 側の鍵管理（Keyring）の稼働 |
| 起動可否への影響 | 認証情報の保存ができず、起動処理自体が止まるケースがある | 「鍵管理サービスに接続できるか」＝起動の前提条件になっていることが多い |
| 再現性 | 環境依存（デスクトップ環境、ログイン方法、Keyring の状態） | 同じ Ubuntu 22.04 でも発生する人／しない人が分かれる |
| 実務的な回避策 | snap を避け、tar.gz / AppImage 版を使う | 「まず動かす」が優先なら、ここが最短ルートになりやすい |
なぜ「password-manager-service」で止まるのか
Azure Storage Explorer は、サブスクリプションやストレージアカウントへのサインイン情報、トークンなどを安全に保持するために、Linux では一般に “秘密情報ストア（Secret Service）” を利用します。Ubuntu 22.04 のデスクトップ環境では、GNOME Keyring がその役割を担うのが典型です。
一方、snap 版アプリはサンドボックス（隔離）環境で動くため、ホスト OS の鍵管理サービスへ自由にアクセスできません。そこで snap は「このアプリは鍵管理サービスを使ってよい」という許可（インターフェイス接続）を明示的に与える必要があります。その許可が不足していたり、許可はしているのに OS 側の Keyring が動いていなかったりすると、起動時点で認証情報ストアに接続できず、アプリが立ち上がらないという形になりがちです。
ポイント：
「snap 側の許可（connect）」と「OS 側の Keyring が正常稼働していること」は別問題です。
connect しても改善しない場合、OS 側の Keyring／セッション周りで詰まっていることがあります。
（最短）3分でできる一次切り分け
時間がないときは、まず次の3つだけ実施して「snap で直る余地があるか」を判断します。
- 接続状態を確認：
snap connections storage-explorerでpassword-manager-serviceが接続されているかを見る - Keyring が生きているか確認：
ps aux | grep gnome-keyringでプロセスが動くかを見る - 直らないなら回避策へ：tar.gz / AppImage 版へ切り替えて作業を止めない
snap 版で試すべき基本の確認と対処
ここからは「snap 版でどうしても直したい」「社内ルール上 snap を使う必要がある」方向けに、できる範囲の切り分け手順をまとめます。
インストール状況とバージョンの確認
「どのビルドを使っているか」「接続が本当に有効か」を最初に見ます。
snap list storage-explorer
snap connections storage-explorer
snap info storage-explorer
snap connectionsで、password-manager-serviceが-（未接続）になっていないかdesktop/wayland/x11などの GUI 関連が未接続になっていないか
必要な snap インターフェイスの再接続
質問内容にもある通り、まずは以下を再接続します。すでに接続済みでも、手動で再実行して状態が変わることがあります。
sudo snap connect storage-explorer:password-manager-service :password-manager-service
sudo snap connect storage-explorer:desktop :desktop
sudo snap connect storage-explorer:wayland :wayland
sudo snap connect storage-explorer:x11 :x11
snap connections storage-explorer GNOME Keyring まわりの確認（導入・ロック解除）
次に、OS 側の鍵管理（Keyring）が本当に使える状態かを確認します。特に次のような条件だと、Keyring が起動していない／ロックされたまま、ということがあります。
- 最小構成の Ubuntu（デスクトップ関連が薄い）
- GNOME 以外のデスクトップ環境（KDE / i3 / sway など）
- 自動ログインや、キーチェーンのパスワードが未設定・未解除
まずは導入が不足していないかを確認します。
sudo apt update
sudo apt install gnome-keyring seahorse
導入後は「パスワードと鍵（Seahorse）」を起動し、以下をチェックします。
- 「Default（デフォルト）キーリング」が存在するか
- 鍵のアイコンがロック状態になっていないか（必要ならアンロック）
- パスワード未設定の場合は、運用上問題ない範囲で設定する（自動ログイン環境では特に重要）
Keyring のプロセスが動いているかは、ターミナルからも確認できます。
ps aux | grep -E "gnome-keyring|secrets" | grep -v grep
ログで「どこで止まっているか」を見る
起動しないときほど、ログが手がかりになります。snap のログと、OS 側の拒否ログを見ます。
# snap アプリ側のログ
snap logs storage-explorer
# AppArmor の拒否が疑わしい場合（DENIED が出ることがあります）
sudo dmesg | grep -i denied | tail -n 50 ここで、鍵管理サービスへのアクセス拒否や D-Bus 周りのエラーが出ているなら、snap 側の制約が原因の可能性が上がります。
GPU 無効で起動テスト（描画系の切り分け）
エラーが「password-manager-service」でも、実際には Electron アプリ特有の描画問題が絡んでいる場合があります。切り分けとして GPU を無効化して起動してみます。
storage-explorer --disable-gpu
ユーザーデータの破損を疑う場合（キャッシュ初期化）
アップデート直後に壊れた場合、設定やキャッシュの破損が原因になることもあります。まずは削除前提のキャッシュ領域だけを退避して再起動を試します。
# 念のためバックアップ（フォルダ名は環境で変わる場合があります）
mkdir -p ~/snap_backup
cp -a ~/snap/storage-explorer ~/snap_backup/storage-explorer_$(date +%Y%m%d)
# キャッシュ削除の例（自己責任：設定が初期化される可能性があります）
rm -rf ~/snap/storage-explorer/common/*
# 再起動
storage-explorer 補足：質問者の環境では、インターフェイス再接続、GNOME Keyring 対応、GPU 無効化を実施しても snap 版では改善しなかった ことが報告されています。
つまり「基本手順で直るケース」もある一方、環境によっては snap 版が根本的に噛み合わないことがあります。
それでもダメなら：snap 特有の「戻せない」問題に注意
snap は便利な反面、特定のアプリでは「過去バージョンへ戻して凌ぐ」がやりにくいことがあります。一般論としては、以前のリビジョンがローカルに残っていれば revert できる場合もありますが、ストア側に旧版が提供されていない／端末に残っていない場合は実質的に不可能です。
# 以前のリビジョンが残っている場合に限り、元に戻せることがあります
sudo snap revert storage-explorer
# 端末に残っているリビジョン一覧（あれば表示されます）
snap list --all storage-explorer 現実的な回避策：snap をやめて tar.gz / AppImage 版を使う
snap 版での起動問題は、鍵管理サービスへの接続やサンドボックス制約が絡むことが多く、環境差で泥沼化しやすいのが実情です。業務で「今日中にストレージを触りたい」「急いでログを確認したい」といった状況では、配布元のリリース（tar.gz / AppImage）を直接使うのが最短です。
| 配布形態 | メリット | 注意点 | おすすめ度 |
|---|---|---|---|
| snap 版 | 更新が楽／依存関係を抱えやすい | 鍵管理や D-Bus 周りで起動不可になることがある | 環境が合えば便利 |
| tar.gz 版 | シンプルに展開して実行／トラブル切り分けがしやすい | 自動更新は自分で管理する | 強く推奨 |
| AppImage 版 | 単体ファイルで持ち運びやすい | 環境によっては FUSE 追加が必要 | 手軽さ重視なら |
GitHub Releases から取得して使う（tar.gz 版）
公式の GitHub リリースページには、Linux 向けの tar.gz / AppImage が並んでいます。ここから目的のバージョンを取得します。
以下は tar.gz 版の例です（ファイル名はバージョンにより変わります）。
# 作業用ディレクトリ（例）
mkdir -p ~/apps/azure-storage-explorer
cd ~/Downloads
# ダウンロードした tar.gz を展開（例）
tar xf StorageExplorer-1.39.1-linux-x64.tar.gz -C ~/apps/azure-storage-explorer
# 実行（展開後のディレクトリ名は環境に合わせて読み替え）
cd ~/apps/azure-storage-explorer/StorageExplorer-1.39.1-linux-x64
./storage-explorer メニューに登録して「普通のアプリ」として起動する（.desktop）
tar.gz 版はそのままだとランチャーに出ないため、.desktop ファイルを作ると運用が楽になります。例として、次の内容を ~/.local/share/applications/azure-storage-explorer.desktop に保存します。
[Desktop Entry]
Name=Azure Storage Explorer
Exec=/home/<user>/apps/azure-storage-explorer/StorageExplorer-1.39.1-linux-x64/storage-explorer
Icon=/home/<user>/apps/azure-storage-explorer/StorageExplorer-1.39.1-linux-x64/resources/app/out/app/icon.png
Type=Application
Categories=Development;Network;
Terminal=false
<user> やパスは自分の環境に合わせて置き換えてください。アイコンのパスはビルドによって変わることがあるため、見つからない場合はディレクトリ内を検索して調整します。
AppImage 版で動かす場合のコツ
AppImage は実行権限を付けるだけで起動できます（ファイル名は例）。
chmod +x StorageExplorer-1.39.1.AppImage
./StorageExplorer-1.39.1.AppImage
もし「FUSE がない」といったエラーで動かない場合は、Ubuntu 22.04 では次のパッケージ追加で解消することがあります。
sudo apt update
sudo apt install libfuse2
.NET 8.0 の確認と導入（報告例ベース）
質問者の環境では「tar.gz 版 v1.39.1」と「.NET 8.0（Ubuntu リポジトリ版）」の組み合わせで正常起動が確認されています。まずは .NET の状態を確認します。
dotnet --info
dotnet --list-runtimes
8.0 系ランタイムが無い場合、apt で提供されていれば次のようなパッケージを導入します（環境により名称は異なるため、事前に apt-cache search dotnet で確認してください）。
sudo apt update
sudo apt install dotnet-runtime-8.0
# 開発環境も必要なら
# sudo apt install dotnet-sdk-8.0
注意：
.NET を Microsoft のリポジトリから入れた場合や .NET 9.0 では、snap 版の問題は解消されなかったという報告があります。
そのため現時点では、「Ubuntu 標準リポジトリの .NET 8.0 ＋ tar.gz 版」が、再現性の高い回避策として扱いやすいです。
旧バージョンを使いたい場合
「v1.38.0 なら動いていたので戻したい」という状況も現場ではよくあります。ただし、snap では旧版が提供されていないとダウングレードできません。そこで、旧版を使うなら次の方針になります。
- GitHub のリリースアーカイブから、目的のバージョン（例：v1.38.0）の tar.gz 版 を取得する
- 任意のディレクトリに展開し、
./storage-explorerで起動する - 別バージョンと共存させたい場合は、ディレクトリを分けて管理する（例：
~/apps/ase/1.38.0と~/apps/ase/1.39.1）
ダウングレードは “根本解決” ではありませんが、業務継続の観点では有効な選択肢です。特に Azure の運用作業では、UI ツールが使えないと調査が止まることがあります。まず作業を進めつつ、後から原因調査をする、という順番が合理的です。
代替手段：Storage Explorer が使えないときに困らないために
Storage Explorer は便利ですが、「GUI が起動しない」だけで業務が止まるのは避けたいところです。普段から代替手段を押さえておくと、今回のようなパッケージ由来のトラブル時にも冷静に対応できます。
| 用途 | 代替手段 | 向いているケース | 最小コマンド例 |
|---|---|---|---|
| Blob の一覧表示 | Azure CLI | 軽く確認したい／スクリプト化したい | az storage blob list --account-name ... --container-name ... |
| アップロード/ダウンロード | AzCopy | 大量転送／高速にコピーしたい | azcopy copy "src" "dst" --recursive |
| GUI での簡易参照 | Azure Portal（ストレージ ブラウザー） | 一時的に確認したい | ブラウザー操作 |
特に障害対応の現場では、AzCopy / Azure CLI の「一覧」「コピー」「削除」「SAS の扱い」だけでも手元に手順書を置いておくと、GUI が使えない状況でも復旧作業を止めずに済みます。
運用のコツ：同じ問題を繰り返さないためのチェックリスト
- まず動かす：snap で詰まったら、tar.gz / AppImage へ切り替えて作業を止めない
- 動いた構成を固定：Storage Explorer と .NET のバージョン、Ubuntu のバージョン、デスクトップ環境を記録する
- アップデートは段階的に：検証端末で確認してから本番端末へ
- Keyring の状態を意識：自動ログインやキーチェーン未解除はトラブルを誘発しやすい
- 代替手段を用意：AzCopy / Azure CLI の最低限の操作を習慣化する
まとめ
Ubuntu 22.04 で Azure Storage Explorer（snap 版）v1.39 以降が起動しない場合、まずは snap のインターフェイス接続と GNOME Keyring を確認します。しかし、環境によってはそれらを整えても改善しないケースがあり、その場合は snap を避けて tar.gz / AppImage 版を使うのが最も安定した回避策です。
特に報告例では「Ubuntu 標準リポジトリの .NET 8.0 ＋ GitHub の tar.gz 版（v1.39.1）」が動作しており、作業継続の実務解として有力です。GUI ツールは便利な一方で依存関係に振り回されがちなので、CLI の代替手段も併せて準備しておくと、いざというときの対応力が上がります。
コメント