自宅のサーバー環境（Raspberry Pi）およびMacにおいて、クラウドストレージサービス「pCloud」を rclone 経由で FUSE マウントして運用しています。
先日、ストレージ容量の追加購入を実施した際、両環境においてマウントポイントへのアクセス障害（Input/output error）が発生しました。本件の原因特定と復旧手順について、備忘録として記録します。
1. 発生した障害の概要
-
現象： Raspberry Pi 上の
rcloneマウントディレクトリ（/mnt/pcloud）に対する操作時にInput/output errorが発生。 -
ログ調査：
journalctlでサービスログを確認したところ、以下の認証エラーが大量に出力されていることを確認。-
pcloud error: Revoked 'access_token' provided, you need to re-authorize the application. (2095)
-
-
同時発症の確認： 同タイミングで Mac 上の
rcloneマウントのpCloud マウントポイントも空（アクセス不能）になっていることを確認。 -
公式アプリとの違い： Windows や Mac の「公式 pCloud アプリ」経由では何の問題もなく正常にアクセスできていたため、当初はアカウント自体の異常ではなく
rclone/ FUSE 固有の障害を疑いました。
2. 原因の特定と切り分け
【原因特定を阻んだタイミングの罠】
-
10月5日： システムの電源落ちが発生し、ログが途中で断絶。
-
10月6日： pCloud で 5TB の容量追加購入（スタック拡張）を実施。
10月5日の電源落ちがあったため、当初は「停電によるファイルシステムの不整合や FUSE プロセスのハングアップ」を最優先で疑っていました。
しかし、Mac 側のマウントも同時にアクセス不能になっていることを発見したことで、「ローカルの電源落ちによる破損ではなく、10月6日の容量追加に伴うアカウント側のトークン一括失効が真の原因である」と論理的に特定することができました。
-
過去（2TB追加時）： 既存のアクセストークンが保持され、再設定なしで運用継続可能であった。
-
今回（5TB追加時）： 大幅な契約変更・スタック拡張に伴い、アカウントのセキュリティ仕様によって発行済みサードパーティアプリのトークンが一括無効化された。
無効化されたトークンのまま systemd や自動スクリプトによる再起動が繰り返されたことで、FUSE プロセスが応答待ち（Dステート）となり、最終的に Input/output error を引き起こしていたことが判明しました。
3. 復旧手順
各端末において、以下の流れで rclone の再認証（Re-authorize）を実施することで正常に復旧しました。
-
プロセスの停止とマウント解除
-
マウントハングを防ぐため、関連サービスを停止し強制アンマウント（
umount -f -l）を実行。
-
-
rclone の再認証
-
ターミナルで
rclone configを実行。 -
e（Edit existing remote） を選択し、pcloudを指定。 -
質問を進め、
Use web browser to automatically authenticate rclone with remote?でyを選択。 -
表示された URL にアクセスし、今度は必ず 「Allow（許可）」 をクリックします。
-
(※ヘッドレスの Raspberry Pi 環境等では、必要に応じて SSH ポートフォワーディングを利用してローカル PC ブラウザ経由で承認を完結します)
-
-
動作確認
-
rclone lsにてファイル一覧が正常取得できることを確認後、サービスおよび関連暗号化ドライブ（Cryptomator 等）の自動マウントを再開。￥
-
4. まとめ・教訓
-
pCloud で大規模な容量追加（5TB等）を行うと、セキュリティ仕様により既存の API トークンを一括失効される場合がある。
-
複数端末で同時マウント不能が発生した場合は、ローカル障害ではなくアカウント層のトークン切れを最優先で疑う。
-
対処としては
rclone configの再認証で即座に正常復旧し、追加購入分の容量もそのまま正しく認識される。
容量追加と電源断のタイミングが重なったことで原因特定に迂回が生じましたが、複数端末の挙動から論理的に絞り込む重要性を再認識する事例となりました。同様の構成で運用されている方の参考になれば幸いです。