occコマンドを使用してownCloudファイルバージョンを安全に削除する
1つのアカウントまたはすべてのユーザーについて、保存されているownCloud Server Classicのすべてのファイルバージョンを削除し、完全削除と保持期間に基づく有効期限切れを区別します。
ownCloud Server Classicの場合、保存済みファイル バージョンを削除する管理者コマンドは ですocc versions:cleanup。削除対象を制限するには、1 つ以上のユーザー ID を追加してください。すべてのユーザーのバージョン履歴を削除する場合のみ、ユーザー ID を省略してください。この操作は破壊的なため、ownCloud データベースとファイル ストレージを事前にバックアップしてください。
架空の例: AlexはClassic ownCloudサーバーを管理しており、廃止されたテストアカウントの古いリビジョンを削除する必要がありますdemo_user。この架空の例では、対象となるコマンドを示し、サーバー全体のクリーンアップと比較しています。実際の実行や結果を説明するものではありません。
以下の手順ではocc、ownCloud Server 10.16 用にドキュメント化されたコマンドラインインターフェイスを使用します。ownCloud Infinite Scale (oCIS) は異なるコマンドセットを使用するため、これらの手順は適用されません。インストールされている製品が不明な場合は、削除を実行する前に管理者に確認してください。
通常のLinuxインストール環境では、ownCloudのインストールディレクトリに移動します。以下のパスはUbuntuの例です。実際のパスを使用してください。
cd /var/www/owncloud
バージョン管理アプリが有効になっていることを確認し、対象とするアカウントIDを検証してください。
sudo -u www-data ./occ app:list --enabled files_versions

files_versionsクリーンアップコマンドを使用する前に、アプリが有効になっていることを確認してください。ownCloudのリファレンスによると、バージョンコマンドは、files_versionsが有効になっている場合にのみ使用可能で、シングルユーザーメンテナンスモードでは使用できません。occファイル権限が一貫しているように、WebサーバーのHTTPユーザーとして実行してください。DebianまたはUbuntuでは通常 ですがwww-data、他のディストリビューションでは別のアカウントを使用する場合があります。ownCloudのoccコマンドリファレンスを参照してください。
履歴を削除する前に、通常のownCloudバックアップ手順に従ってバックアップを作成してください。データベースと、ユーザーのファイルおよびバージョンが保存されているストレージの場所を含めてください。バックアップが完了し、復元できることを確認してください。データベースのみのコピーには、実際のバージョンファイルが含まれていない場合があります。
アレックスの想定するケースでは、対象範囲は のみですdemo_user。ユーザー ID はこのサーバー上のアカウントと一致している必要があります。コマンドはユーザー ID を受け入れるため、メールアドレス、表示名、または別のユーザー名に置き換えないでください。特にディレクトリ サービス内の名前がログイン ID と異なる場合は、コマンドを実行する前に ownCloud のユーザー管理でアカウント識別子を確認してください。
このアカウントのすべての古いバージョンを削除することが目的の場合は、 を使用してくださいversions:cleanup。このコマンドにはドライランオプションが文書化されていないため、実行する前にターゲットとバックアップを確認してください。この操作のためにサーバーをシングルユーザーメンテナンスモードにしないでください。ownCloud のドキュメントには、そのモードでは Versions コマンドが使用できないと記載されています。
通常のLinuxインストールでは、ownCloudディレクトリからHTTPユーザーとしてコマンドを実行します。DebianまたはUbuntuでは、Alexは次のように実行します。
sudo -u www-data ./occ versions:cleanup demo_user

demo_userクリーンアップの対象をそのownCloudアカウントに限定する設定を追加する。記載されている構文では、versions:cleanup [user_id]...1つ以上のアカウントIDを受け入れます。IDが指定されていない場合は、すべてのユーザーのバージョン管理されたファイルが削除されます。グローバルフォームは、その範囲を明示的に承認した後にのみ使用してください。
sudo -u www-data ./occ versions:cleanup

ownCloud の例では、ID が指定されていない場合に削除対象ユーザーをすべて識別するコマンドが示されています。ID を指定すると、操作はそれらのアカウントに絞り込まれます。また、通常の保持ポリシーでは期限切れにならない場合でも、このコマンドを使用すると管理者が公開済みの永続的なメジャー バージョンを削除できることがマニュアルに記載されています。承認済みまたは公開済みのリビジョンが含まれている可能性のあるアカウントを削除する前に、コンテンツ所有者に確認してください--no-interaction。プロンプトをスキップするために追加しないでください。コンテナのインストールの場合、ドキュメントに記載されているパターンは ですdocker exec --user www-data <owncloud-container-name> occ <your-command>。プレースホルダーを実際のコンテナ名と選択したコマンドに置き換えてください。デプロイメントで別のコンテナ ユーザーを使用する場合は、Docker および occ の手順を参照してください。
Alexが、設定された保持ポリシーに基づいて期限切れとなったバージョンのみをownCloudから削除したい場合、より適切なコマンドは次のようになります。
sudo -u www-data ./occ versions:expire demo_user

versions:expire設定された保持ルールを適用しますが、保存されたすべてのバージョンを削除することを保証するものではありません。ownCloud のリファレンスでは、versions:expireは に従って期限切れになったバージョンのみを削除すると定義されていますversions_retention_obligation。これに対し、は選択した範囲内のすべてのバージョンを削除します。ポリシーを変更する前に、ドキュメントに記載されているバージョン保持設定versions:cleanupを確認してください。 設定はバージョンの削除を無効にします。既に保存されているバージョンは削除されません。disabled
この記事ではownCloud Server Classicについて説明します。Infinite Scaleには独自の改訂クリーンアップコマンドがありますので、そちらを実行するのではなく、oCISの改訂クリーンアップに関するドキュメントoccを参照してください。
コマンドがエラーなく完了したら、対象アカウントが所有するファイルのバージョンビューを開きます。以前のリビジョンがリストに表示されなくなり、現在のファイルが存在することを確認してください。全ユーザーのクリーンアップを行う場合は、対象コマンドがグローバルに実行されたと想定するのではなく、代表アカウントを確認してください。所有者が履歴バージョンが不要であることを確認するまで、バックアップを保持してください。保持スケジュールを満たすことが目的の場合は、versions:expire完全な削除がすぐに完了することを期待するのではなく、そのポリシーに従って検証してください。
このコマンドはファイルバージョン管理専用です。削除済みファイルゴミ箱内のアイテムをクリアしたり、バックアップアーカイブを削除したり、現在のファイル自体を削除したりするものではありません。これらは別のデータ保持タスクとして扱ってください。ドキュメントに記載されているコマンドの代わりに、バージョンディレクトリを手動で削除しないでください。
1つのアカウントまたはすべてのユーザーについて、保存されているownCloud Server Classicのすべてのファイルバージョンを削除し、完全削除と保持期間に基づく有効期限切れを区別します。
ownCloudモバイル接続拒否の原因を特定するには、サーバーURL、電話ネットワーク、HTTPSエンドポイント、およびサーバーログを正しい順序で確認してください。
オンデマンドのジョブ実行を、ownCloudでサポートされているocc system:cronコマンドを15分ごとに実行するsystemdタイマーに置き換えます。
Apache、Nginx、またはリバースプロキシを経由してWebDAVリクエストをトレースし、認証済みのPROPFINDテストを使用してownCloudの同期が機能することを確認します。
Nextcloudの送信アドレスが見つからないという警告を修正するには、正規URLを設定し、サーバー自体からDNS、HTTPS、およびリバースプロキシルーティングを確認してください。
Nextcloudのキャッシュとファイルロックのために、ローカルのUnixソケットを介してAPCuとRedisを設定する手順を、最新版および旧版のNextcloudリリースごとに説明します。
Nextcloudのcronモードを確認し、systemdサービスとタイマーを修復し、起動後および5分ごとにバックグラウンドジョブが実行されていることを確認してください。
信頼性の高いNextcloudファイルロックを有効にし、適切なRedisまたはValkeyバックエンドを選択し、同時ファイル変更のリスクを冒すことなく警告が解消されることを確認してください。
最新のアップデート、HTTPSおよびHSTS、正確なリバースプロキシの信頼設定、およびパブリックサーバーに対するチェックによって、Nextcloudのスキャンでよく見られる問題を修正します。
必要なストレージに対してNextcloud SSEを設定し、暗号化キーを保護し、既存ファイルを暗号化する前に転送量とCPUへの影響を測定します。