ownCloudのファイルを共有を失うことなく新しい所有者に移動する

現在ownCloudアカウントから退会または変更されるアカウントが所有するファイルの所有者を別のユーザーに変更するには、サーバー側のocc files:transfer-ownershipコマンドを使用します。このコマンドは、デフォルトでは所有するすべてのファイルと、共有フォルダおよび関連するメタデータを移動します。--pathフォルダのみを転送する必要がある場合は、このコマンドを使用してください。Web共有パネルはアクセス権限を変更しますが、所有権を移転するメカニズムではありません。

適切な転送範囲を選択してください

ownCloud Classicでは、所有権によって、元のアイテムが誰の個人ファイルスペースに保存されているか、そしてどのユーザーアカウントが送信先の共有を管理しているかが決まります。編集権限を持つ受信者は依然として受信者であり、「編集可能」の権限を付与しても、そのユーザーがファイルの所有者になるわけではありません。転送を実行する前に、新しい所有者がアカウント全体のファイルを必要とするのか、特定のプロジェクトフォルダのみを必要とするのかを判断してください。

• すべてのファイルを転送する：アカウントが廃止され、所有ファイルと共有フォルダをまとめて移動する必要がある場合に使用します。範囲設定は簡単ですが、単一のチームによる引き継ぎでは対応できないほど多くのコンテンツを転送することになります。
• フォルダを1つ転送する：ソースユーザーのファイル内の特定のディレクトリに使用します--path。これにより範囲は縮小されますが、転送を開始する前にネストされたコンテンツと共有関係を確認してください。
• 永続的なチーム共有を維持する：継続的なチームコンテンツについては、ownCloudは専用のオーナーアカウントを推奨します。このアカウントの共有フォルダは、スタッフの交代があってもそのまま維持されます。これは、将来のファイルのためのガバナンス上の選択であり、既存のオーナーのファイルを遡って転送するものではありません。

ownCloud Server 11の公式共有ドキュメントによると、このコマンドは送信する共有ファイルと、タグやコメントなどの関連メタデータを転送します。受信する共有ファイルは、元のファイルが別のユーザーの所有物であるため転送されません。ゴミ箱の内容も転送されません。

会計帳簿とデータを準備する

送信元と送信先のユーザーIDを正確に確認してください。これらはアカウント識別子であり、表示名やメールアドレスである必要はありません。送信先のアカウントが存在し、転送するデータがそのアカウントの容量制限内に収まることを確認してください。ownCloudのコマンドリファレンスには、一部のバージョンではターゲットユーザーが存在しない場合に作成される可能性があると記載されていますが、事前に目的のアカウントを作成して確認することで、意図しないIDでデータが移動されることを回避できます。

ユーザーがソースファイルを編集していない時間帯に操作をスケジュールしてください。ownCloud のデータとデータベースの検証済みバックアップを作成し、復元手順を把握しておいてください。データディレクトリ内でファイルを直接コピー、名前変更、または移動しないでください。データベースはファイルのメタデータと所有権を追跡します。ownCloudoccがレコードと共有を一貫して更新できるように、適切な設定を使用してください。

ownCloudの現在のClassic版ドキュメントには、Server 11.0と10.16のマニュアルが別々に用意されています。Server 11ではDockerベースのインストール方法が説明されていますが、10.16の例では従来のPHPインストール方法が使用されています。コマンドをそのままコピーするのではなく、デプロイ済みのリリースに合ったコマンド形式を使用してください。

所有権移転を実行する

ownCloud Classic 11（Docker版）

Composeデプロイメントを含むディレクトリから、ソースアカウントが所有するすべてのファイルを宛先アカウントに転送します。

docker compose exec owncloud occ files:transfer-ownership \
  source-user \
  destination-user

両方のサンプルIDを、実際のownCloudユーザーIDに置き換えてください。コマンドの出力と、スキップされた共有に関するプロンプトを確認してください。スキップされた共有を自動的に受け入れるオプションは、その結果を確認し、同意するまで追加しないでください。

ownCloud Classic 10.16にPHPをインストールした場合

occownCloudのインストールディレクトリから、ウェブサーバーユーザーとして実行してください。多くのDebianまたはUbuntu環境では、そのユーザーは次のとおりですwww-data。

sudo -u www-data php /var/www/owncloud/occ files:transfer-ownership \
  source-user \
  destination-user

実行ファイルのパスとアカウントをホストに合わせて調整してください。コマンドが不明なオプションまたはコマンドを報告する場合は、インストール済みのownCloudのコマンドリファレンスを確認してからocc files:transfer-ownership --help再試行してください。

転送先をフォルダに限定する

すべてのファイルではなく、プロジェクトディレクトリ名を指定して移動するにはProjects、ユーザーIDの前にパスオプションを追加します。

docker compose exec owncloud occ files:transfer-ownership \
  --path="Projects" \
  source-user \
  destination-user

パスは 内に存在する必要がありますdata/<source-user>/files。ownCloud は単に宛先の同じ相対パスにフォルダを配置するわけではありません。転送されたコンテンツは、transferred from <source-user> on <timestamp>宛先ユーザーのファイル内の という形式のディレクトリに保存されます。コマンド完了後に受信者がコンテンツを見つける場所を指示してください。利用可能なオプションについては、ownCloud 10.16 occ コマンドのリファレンスを参照してください。

このコマンドが不適切なツールであることを認識してください。

転送は、送信元ユーザーに表示されるすべてのアイテムに対して、所有者を変更する一般的なボタンではありません。受信共有内のファイルは元の共有者に帰属し、移動されません。必要なコンテンツが受信共有である場合は、その所有者と調整するか、承認済みのワークフローを使用して別のコピーを作成してください。コピーは別のファイルであり、元の共有履歴やメタデータが保持されない場合があります。

ストレージ固有の制限事項もあります。ownCloudのドキュメントでは、複数のバケットで構成されたS3プライマリストレージでこのコマンドを使用すると、ファイルの共有が失われる可能性があるため、使用しないように警告しています。エンタープライズファイルライフサイクルアーカイブにも、転送に関する制限事項が記載されています。これらのいずれかの機能が該当する場合は、バージョン固有のドキュメントを確認し、実行前に代表的な非本番環境アカウントで手順をテストしてください。

転送中に例外が発生したり、途中で停止したりした場合は、すぐに転送を繰り返さないでください。ownCloudの共有ガイドでは、occ files:troubleshoot-transfer-ownership --uid <uid>転送状態を調査して修復するために、送信元と送信先の両方のユーザーIDでコマンドを実行することを推奨しています。結果が理解できるまで、元のログとバックアップを保存してください。

ソースアカウントを削除する前に結果を確認してください

転送先のユーザーとしてサインインし、生成された「転送元」ディレクトリの下に転送されたフォルダが表示されていることを確認します。代表的なファイルを開き、想定されるフォルダ、タグ、コメント、および送信先共有を確認します。転送先の受信者の1人に、既存の共有経由でアクセスできることを確認してもらいます。次に、送信元アカウントに残っている所有ファイルまたは共有を確認し、コマンド出力でスキップされた項目がないか確認します。

宛先アカウントの所有者と関連する共同作業者がアクセスを確認した後でのみ、送信元アカウントを削除または無効化してください。ownCloudはファイルを所有者に紐付けているため、ユーザーを削除すると、そのユーザーに残っているファイルと共有フォルダも削除される可能性があります。転送コマンドではゴミ箱や受信共有フォルダは移動されません。これらの制限事項は、引き継ぎチェックリストに含める必要があります。