ownCloudのファイルロック「ロックメカニズムタイムアウト」エラーを修正する方法

ownCloudで同期、アップロード、移動、名前変更、またはチャンクアセンブリ中にファイルロックのタイムアウトが報告された場合、まず知っておくべきことは、このエラーは通常、ユーザー向けの「手動ファイルロック」機能ではなく、トランザクションファイルロックに関連しているということです。トランザクションロックは、2つのリクエストが同時に同じファイルを保存または変更することを防ぐ内部的な安全メカニズムです。ownCloudではデフォルトで有効になっており、データベースまたはRedisをロックバックエンドとして使用できます。

ownCloud 11の最新ドキュメントでは、トランザクションファイルロックには引き続きRedisの使用を推奨しています。これは、データベースを介したロックはデータベースに大きな負荷をかけるためです。クラスタ構成の場合、すべてのアプリケーションノードはロックに同じ共有Redisインスタンスを使用する必要があります。タイムアウト値を変更したり、ロックレコードを削除したりする前に、この点を理解しておくことが、永続的な解決策となります。

このガイドでは、初心者管理者の視点から問題を解説します。ロックの意味、バックアップすべきもの、障害が発生しているコンポーネントの確認方法、Redisの設定方法、クラスタリングによる状況の変化、そして状況を悪化させる可能性のあるショートカットについて説明します。

エラーの意味

ownCloudがファイルを変更する際、ロックを取得します。これにより、他のリクエストが同時に互換性のない変更を行うことを防ぎます。ロックは親ディレクトリにも適用されるため、作業中は親ディレクトリの名前を変更することはできません。ロックを時間内に取得できない場合は、ファイルが破損するリスクを避けるため、ロックされたリソースまたはタイムアウトのようなエラーで操作が失敗します。

ownCloud 11のトランザクションファイルロックに関するドキュメントによると、このメカニズムは、中断されたアップロード、共有ファイル、外部ストレージ、および暗号化されたファイルにも対応しています。

これは、ユーザーがWebインターフェース上で意図的にファイルをロックできるオプションのWebDAVベースのチェックイン/チェックアウト機能である「手動ファイルロック」とは異なります。手動ロックには、ユーザーが設定可能な有効期限があります。これらの値を変更しても、過負荷状態または設定ミスのあるトランザクションロックバックエンドは修正されません。

始める前に

• ownCloudデータベースをバックアップしてconfig/config.php、
• ownCloudのバージョンとデプロイの種類（従来のパッケージ、Docker Compose、またはマルチノードクラスター）を記録してください。
• 使用しているデータベースエンジンと、Redisが既にインストールされているかどうかを確認してください。
• デスクトップ同期、WebDAVアップロード、フォルダ名の変更、チャンクアップロードなど、失敗した操作を正確に記録してください。
• 問題が1つのファイル、1人のユーザー、または複数のユーザーに同時に影響しているかどうかを記録してください。

多くのユーザーに影響を与える広範囲な障害は、通常、ロックバックエンド、データベース、Redis、ストレージなどの共有コンポーネントに問題があることを示しています。一方、特定のファイルで繰り返し発生するエラーは、実際にアクティブな操作、またはまだ有効期限が切れていない古いロックが原因である可能性があります。

ステップ1：どのロック機構が故障しているかを確認する

ownCloudのログ、Webサーバーのログ、PHP-FPMのログ、およびRedisサービスのステータスを確認してください。繰り返し発生するロックされたリソース例外、データベースのロック待機エラー、Redis接続の失敗、または元の操作が終了した後も長時間同じパスがブロックされたままになっているパターンを探してください。

Linuxホストで役立つチェック項目には以下のようなものがあります。

systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.log

正常な Redis コマンドは を返しますPONG。ownCloud がソケット、コンテナホスト名、パスワード、またはリモート ホストを介して Redis にアクセスするように構成されている場合は、ローカル テストでアプリケーションの接続が証明されると想定するのではなく、ownCloud が実際に使用するのと同じ接続パスをテストしてくださいredis-cli。

ログに「ロック待機タイムアウト超過」のようなデータベースメッセージが含まれている場合は、データベースの競合についても調査してください。古いデータベースロックバックエンドは機能していますが、ownCloudのドキュメントには、データベースに大きな負荷がかかることが明記されています。

ステップ2：トランザクションファイルロックをRedisに移行する

従来のownCloudインストールの場合、memcache.lockingバックエンドとしてRedisを設定しますconfig/config.php。現在のownCloudメモリキャッシュのドキュメントには、次のようなRedis TCPの例が記載されています。

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'password' => '',
],

インターネットに公開されているRedis環境に、空のパスワードをそのままコピーしないでください。ownCloudのメモリキャッシュに関するドキュメントでは、Redisを適切に保護することを推奨しています。理想的には、Redisには信頼できるownCloudホストまたは内部コンテナネットワークからのみアクセスできるようにすべきです。

ownCloudの公式Docker構成では、Redisは環境変数によって有効化されています。現在のownCloud 11のドキュメントには以下のように記載されています。

OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379

そのデプロイメントモデルでRedisが有効になっている場合、ownCloudは分散キャッシュとロックキャッシュの両方を自動的にRedisに設定します。どちらのレイヤーが優先されるかを理解していない限り、Docker環境変数と手動で管理する設定を混在させるのではなく、インストール用に文書化されたデプロイメント固有の設定をconfig.php使用してください。

ステップ3：クラスタでは、すべてのノードが同じRedisを使用するように設定します。

クラスターとは、ロードバランサーの背後に複数のownCloudアプリケーションサーバーを配置した構成です。この構成では、あるアプリケーションノードで作成されたロックは、他のすべてのノードから参照できる必要があります。ノードごとのAPCuキャッシュや、ノードごとに個別のRedisインスタンスを使用しても、共有ロック状態を提供することはできません。

ownCloudのクラスタ型共有ストレージガイドには、すべてのアプリケーションノードからアクセス可能な単一の共有Redisインスタンスを使用することが明記されています。また、ownCloudのアプリケーションレベルのロックにファイルシステムロックやNFSロックを使用することは避けるべきだと警告しています。

すべてのノードで同じRedisエンドポイントと認証情報が使用されているか確認してください。よくある障害パターンとして、1つのノードがデータベースまたはローカルのRedisを使用している一方で、他のノードは共有サービスを使用しているというケースがあります。これにより、ロックの動作に一貫性がなくなり、各リクエストを処理するアプリケーションノードによって結果が異なるため、断続的な問題が発生する可能性があります。

ステップ4：設定を確認し、元の操作を再試行します。

Redisの設定後、ownCloudのアクティブな設定を`.`コマンドで確認してくださいocc。インストール環境によっては、このコマンドはWebサーバーユーザーとして、またはDocker Compose経由で実行できます。

sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabled

最初のコマンドは を報告し\OC\Memcache\Redis、トランザクションファイルロックは有効なままにしておく必要があります。ファイルロックを無効にすることで問題を「解決」しないでください。それはバックエンドを修正するのではなく、データ整合性の保護機能を失うことになります。

失敗した操作を再度実行してください。デスクトップクライアントのアップロードがタイムアウトした場合は、そのアップロードを再度実行してください。フォルダの移動が失敗した場合は、移動を再度実行してください。テスト中はownCloudとRedisのログを監視してください。ロックタイムアウトが繰り返し発生せずに再試行が成功すれば、無関係なメンテナンスコマンドを実行するよりもはるかに強力な証拠となります。

ファイルがまだロックされているように見える場合はどうすればよいですか？

まず、他の操作が実際にまだファイルを使用しているかどうかを判断してください。大容量ファイルのアップロード、外部ストレージへのアクセス、ファイルの移動、暗号化、または低速なストレージ処理は、想定よりも長くロックを保持する可能性があります。操作がまだアクティブな状態でロックを解除すると、ロックが防止するように設計されていた競合状態が発生する可能性があります。

トランザクションロックは、トランザクションが中断された後に解放されるように設計されています。古いownCloudの設定リファレンスには、古いロックを自動的にクリーンアップするためのロックの有効期限（TTL）メカニズムも記載されています。設定の詳細はownCloudのリリースによって異なる場合があるため、変更する前に、インストールされているバージョンに一致するオプションをドキュメントで確認してください。ストレージやデータベースの低速な問題を隠すためだけに、TTLを極端に短く設定しないでください。

メタデータ自体に矛盾がある場合、ownCloudは修復を目的としたファイルスキャンコマンドを提供します。公式のoccコマンドのドキュメントでは、修復スキャンを実行する前にデータベースをバックアップすることを推奨しています。修復スキャンは、破損または矛盾したファイルメタデータに対応するためのものであり、通常のロック競合に対する第一選択の解決策ではありません。

トランザクションロックと手動ファイルロックを混同しないでください。

ownCloud 11の最新ドキュメントによると、手動ファイルロックはウェブインターフェースではデフォルトで無効になっています。有効にした場合、ウェブインターフェースのロック時間はデフォルトで30分、最大で24時間です。これらの値については、「手動ファイルロックガイド」に記載されています。

問題がユーザーが作成した手動ロックに関するものである場合は、次のようなコマンドが役立ちます。

docker compose exec owncloud occ config:app:set files lock_timeout_default --value 1800
docker compose exec owncloud occ config:app:set files lock_timeout_max --value 86400

ファイルの同期または保存中に内部タイムアウトが発生している場合、これらの手動ロック値を変更することは通常、適切な解決策ではありません。

ロックタイムアウトを悪化させるよくある間違い

ownCloudがアクティブな状態で、データベースからロックされた行を削除する

これは、実行中のリクエストと競合したり、有効なロックを解除したりする可能性があります。また、タイムアウトの原因となっているデータベースやRedisの設定を修正することなく、症状だけを一時的に抑えることになります。

トランザクションファイルロックを無効にする

トランザクションロックは、ファイル操作が同時に変更されるのを防ぐために存在します。これを有効にして、バックエンドを修復してください。

クラスタ内での共有ロックにAPCuを使用する

APCuはノードごとのローカルキャッシュです。ローカルキャッシングには適していますが、複数のアプリケーションサーバー間で共有されるロック状態は提供しません。クラスタ構成における分散キャッシュおよびロックキャッシュには、共有Redisを使用してください。

アプリケーションノードごとに1つのRedisインスタンスを実行する

そのため、各サーバーはファイルロックに関して異なるビューを持つことになります。ロック調整のためには、すべてのノードで同じ共有Redisサービスが必要です。

競合を解消せずにデータベースのロック待機時間を長くする

データベースのタイムアウト時間を長くすると、ユーザーの待ち時間が長くなるだけです。トランザクションロックの処理をRedisに移行することで、データベースのロック負荷が軽減され、アーキテクチャ上のボトルネックが解消されます。

ロックの有効期限を非現実的に短くする

外部ストレージの操作や大容量ファイルのアップロードには、当然ながら時間がかかる場合があります。ロックを期限切れにすると、同じリソースを同時に変更しようとする別のリクエストが発生できるようになります。

簡単なトラブルシューティングチェックリスト

• エラーが、ユーザーが作成した手動ロックではなく、トランザクションロックに関連していることを確認してください。
• ownCloud、PHP、データベース、およびRedisのログを、ほぼ同じタイムスタンプの箇所で確認してください。
• Redisがシェルからだけでなく、ownCloudランタイムからもアクセスできることを確認してください。
• memcache.lockingに設定します\OC\Memcache\Redis。
• 有効のままにしてくださいfilelocking.enabled。
• クラスター環境では、すべてのノードを同じRedisインスタンスに接続します。
• ログを監視しながら、元の同期、アップロード、または移動を再試行してください。
• メタデータの破損や古いロックの存在を示す証拠がある場合にのみ、修復スキャンまたはロック有効期限の変更を実行してください。

結論

ownCloudのファイルロックタイムアウトエラーに対する最も確実な解決策は、ロックを削除したり、タイムアウト値を任意に引き上げたりしないことです。まず、エラーの原因がトランザクションロックにあるかどうかを特定し、そのロック処理をRedisに移行して、すべてのownCloudノードが同じRedisインスタンスを参照していることを確認してください。それでもロックが長時間アクティブなままの場合は、失敗した操作を正確に再テストし、データベースまたはストレージのレイテンシを調査してください。

このアプローチは、現在のownCloudのドキュメントに準拠しています。トランザクションファイルロックは有効なままで、Redisが共有ロック状態を処理し、手動ファイルロックのタイムアウト設定は、普遍的なロックタイムアウト修正ではなく、個別の機能として扱われます。