トラブルシューティング

よくある問題への対処方法です。

管理者のパスワードを忘れた

docker exec -it thirtyfile thirtyfile reset-password admin

求められたら新しいパスワードを入力します。こうするとシェルの履歴に残りません。無効になっているアカウントも、この操作で再び有効になります。

docker exec thirtyfile sh が動かない

イメージには ThirtyFile 本体だけが含まれ、シェルやほかのプログラムはありません。その分、更新が必要なものを減らしています。docker exec thirtyfile thirtyfile reset-password … など、ThirtyFile のコマンドはガイドのとおりに使えます。ファイルを見るには、ホストの data と storage フォルダー、または docker cp を使ってください。

管理者がスマートフォンと回復コードをなくした

ほかの管理者が コントロールパネル › ユーザー でリセットできます。ほかに管理者がいない場合は、サーバーで無効にします。

docker exec thirtyfile thirtyfile reset-two-factor admin

共有リンクが http://127.0.0.1:8080 で始まる

コントロールパネル › 全般 › サイトの URL に、利用者がアクセスするアドレスを設定します。

サインイン直後にサインアウトされる

THIRTYFILE_SECURE_COOKIE が true なのに、http:// で開いている状態です。https:// で開くか、HTTPS を使わない場合は設定を false にします。

全員に「失敗した試行が多すぎます」と表示される

リバースプロキシの背後では、THIRTYFILE_TRUST_PROXY を true にする必要があります。プロキシが別のコンピューターで動く場合は、そのアドレスを指定します。プロキシも 設定例 のとおりに利用者のアドレスを転送する必要があります。そうしないと、全員が同じ利用者として数えられます。

制限は 15 分後に自動で解除されます。

同じアカウントへのパスワード入力が何度も失敗すると、送信元のアドレスにかかわらず、次の試行までの待ち時間が少しずつ長くなり、最大 1 分になります。アカウント自体はロックされません。

大きなファイルのアップロードに失敗する

413 エラーの場合は、THIRTYFILE_MAX_UPLOAD_MB とリバースプロキシのリクエストサイズ上限を両方確認してください。ブラウザーのアップローダーは 32 MB のチャンクを使います。nginx の例 のように、1 リクエストあたり少なくとも 64 MB を許可します。WebDAV はファイル全体を 1 リクエストで送るため、そのファイルが収まる上限が必要です。WebDAV のトラブルシューティング も参照してください。スペースの容量制限と保存先の空き容量も確認します。

起動時に「Permission denied」と表示される

起動時にコンテナーはフォルダーの所有者をユーザー 1000 に変更します。次の 2 つの場合は変更できません。

• --user を指定して起動している場合。そのユーザーが書き込めるようにします。sudo chown -R 1000:1000 /srv/thirtyfile の 1000 を、そのユーザーの番号に置き換えてください。
• 所有者を変更できないネットワーク共有上のフォルダーを使っている場合。ログに Can't give the folder … to user と表示されます。THIRTYFILE_RUN_AS に、その共有のファイルを所有するユーザーとグループ、たとえば 1026:100 を指定してください。

ログを見る

docker logs --tail 100 thirtyfile

稼働状態を確認する

http://files.example.com:8080/api/health はサーバーの状態を返します。通常は "status": "ok"、/data または /storage の空き容量が 1 GB 未満の場合、保存場所に接続できない場合、または過去 1 日以内にバックグラウンド処理がエラーで止まり再起動した場合（どの処理かはログに出ます）は "degraded" です。両フォルダーの空き容量と総容量、各保存場所が ok か offline かも返すので、ディスクがいっぱいになる前に監視ツールで警告できます。アップロードと WebDAV で送られたファイルはまず /data に受け取るため、受け取った後の /data の空きが 64 MB を切る場合は受け付けません。監視では JSON の status を確認してください。状態が degraded でも HTTP 200 を返します。データベースの確認に失敗すると、HTTP 503 と "status": "error" を返します。Docker のヘルスチェックは HTTP 200 を正常とするため、空き容量不足や保存場所のオフラインだけでコンテナーが再起動することはありません。状態低下の警告は、ログに最大 1 時間に 1 回記録されます。

これらの詳細は、リバースプロキシを通さずサーバー自身から送られた要求と、サインイン中の管理者にだけ返されます。それ以外には status だけが返されます。

誰でもアクセスできるため、バージョンは返しません。知らない人に、既知の問題を調べるためのバージョン情報を渡さないためです。サインイン後は アカウントメニュー の最後の行に、たとえば ThirtyFile 0.5.0 と表示されます。管理者は コントロールパネル の右下でも確認でき、そのリリースノートへのリンクになっています。サーバーでは docker exec thirtyfile thirtyfile --version で表示できます。

保存されたファイルを確認する

データベースにあるすべてのファイルが保存場所に残っているか、データベースにないファイルが保存場所に残っていないか（手作業で置いたものなど）を確認します。

docker exec thirtyfile thirtyfile check

すべての保存場所について、見つからないファイル、サイズが違うファイル、不明なファイルを一覧表示し、問題があれば終了コード 1 を返します。不明なファイルは削除しません。--verify を付けると、すべてのファイルを読み直して内容のフィンガープリント（SHA-256）と比較するため、全データを読むだけの時間がかかります。フォルダースペースは対象外です。そのファイルはディスク上の通常のファイルです。

フィンガープリントはアップロード中に計算され、一時停止や ThirtyFile の再起動をまたいでも引き継がれます。大きなアップロードの完了時に、全ファイルをもう一度読み直すことはありません。後からディスクに同じ内容が残っているかを確認するのが --verify です。

ファイルを保護する仕組み

• パスワード、アプリパスワード、回復コード、サインインセッションは、元の値を読み出せない形式で保存します。
• パスワードでサインインする全員に 2 段階認証を必須にできます。
• アプリパスワードでアクセスできるのはファイルだけです。アカウントやコントロールパネルにはアクセスできません。アカウント を参照してください。
• アップロードしたファイルから、サイト上でスクリプトは実行できません。
• 共有リンクの作成者がアイテムへのアクセスを失うと、そのリンクも使えなくなります。
• パスワードやアプリパスワードの入力に繰り返し失敗すると、15 分間ブロックされます。

解決しない場合

行った操作、期待した結果、実際に起きたことを添えて、GitHub で問題を報告 してください。