著者 HRConvert2をセルフホストする方法と設定
HRConvert2を自分のVPSで動かし、顧客ファイルを無料変換サイトに送らない方法です。DockerまたはApache、bubblewrap、アップロード制限、削除設定を解説します。
ファイルコンバーターをセルフホストする理由
セルフホスト型のファイルコンバーターを使うと、ファイルを自分のディスク上に保存できます。これが運用する理由のすべてです。無料のコンバーターサイトでは、アップロードしたファイルがその後どう扱われたかを知る手段がありません。署名済みの顧客契約書やスキャンした診療記録であれば、アップロード自体がインシデントになります。HRConvert2 は PHP で書かれ、GPLv3 のライセンスで提供される、ドラッグアンドドロップ式のファイル変換サーバーです。Version 3.7.4 は 18 August 2026 にリリースされ、プロジェクトでは 488 種類の形式に対応しているとしています。
データベース、アカウント、Cookie はありません。ユーザーごとに一時ディレクトリが作成されます。変換処理はすべて、ローカルのコマンドラインツールが実行します。文書には LibreOffice、音声と動画には FFmpeg、画像には ImageMagick、光学文字認識（OCR）には Tesseract を使い、その他の形式には多数の小規模なツールを使います。HRConvert2 は、アップロード画面、変換パイプライン、そしてそれらの後処理を担います。
ファイルを別の形式へ変換します。ブラウザー上で文書を編集するオフィススイートではありません。タブ内で複数のユーザーが文書を編集する環境が必要なら、セルフホスト型の OnlyOffice と Collabora を比較してください。ストレージでもありません。変換後のファイルは削除することを前提としています。ファイルを保存する必要がある場合は、セルフホスト型のファイルマネージャーがその役割を担います。
必要なもの
Debian または Ubuntu、Apache 2.4、PHP 8 以降、および bubblewrap が必要です。Bubblewrap (bwrap) はサンドボックスとして動作し、省略できません。サンドボックスを構築できないサーバーでは、サンドボックスなしで実行するのではなく、変換を拒否します。上流の README では Raspberry Pi Model B+ で十分とされています。これは PHP 部分については正しい説明です。実際に必要なハードウェアの性能は変換バイナリによって決まり、その点は後述します。
導入方法は2つあります。Docker イメージならすぐに動かせます。Apache と PHP をインストールする方法では、作業に数時間かかりますが、サーバー上に何が構成されているかを正確に確認できます。
Docker で今夜実行する
このイメージにはすべての変換バイナリが含まれるため、大容量です。2026 年 8 月時点で約 3 GB あります。pull する前に空きディスク容量を確認してください。
ここではタグが重要です。2026 年 8 月 17 日時点で Docker Hub に公開されている最新タグは v3.7.2 で、最新の GitHub リリースは v3.7.4 です。latest タグは予告なく変わるため、このアプリケーションは解析対象が広いことも考慮し、バージョンを固定して意図的にアップグレードしてください。
docker pull zelon88/hrconvert2:v3.7.2
docker run -d --name hrconvert2 \
-p 127.0.0.1:8080:80 \
--security-opt seccomp=unconfined \
zelon88/hrconvert2:v3.7.2docker ps
curl -I http://127.0.0.1:8080/正常なコンテナは Up 状態を維持し、curl は HTTP/1.1 200 OK を返します。コンテナが再起動を繰り返す場合は起動時の問題があるため、ほかの変更を行う前に docker logs hrconvert2 を確認してください。
重要なフラグが 2 つあります。-p 127.0.0.1:8080:80 は loopback のみにポートを公開するため、意図的にプロキシを前段に置くまで変換サービスへ外部から到達することはありません。プロジェクト独自の例では -p 8080:80 -p 8443:443 をマッピングしており、パブリックなインターフェースを含むすべてのインターフェースで待ち受けます。--security-opt seccomp=unconfined が必要なのは、bubblewrap が user namespace と mount のシステムコールを使って sandbox を構築し、Docker のデフォルト seccomp プロファイルがそれらをブロックするためです。このフラグがないと変換に失敗し、アプリケーションは理由を示します。A sandbox blocks the required syscalls unless it was started with the correct options.
このフラグには実際のトレードオフがあります。コンテナの syscall フィルターを緩和することで、アプリケーションはコンテナ内に独自の、より厳格な sandbox を構築できます。動作を決める設定は Resources/config.php 内の $RequireSandbox と $RequireSandboxOnDocker で、デフォルト値はそれぞれ TRUE と FALSE です。Docker の要件はデフォルトで無効なため、seccomp フラグなしのコンテナでは sandbox なしで変換できます。フラグを設定したら $RequireSandboxOnDocker = TRUE; を設定すると、コンテナ内でも拒否動作が有効になります。
このマシンで Docker を初めて使用する場合は、先に daemon を設定してください。VPS で Docker を実行するでは、インストール、storage driver、Docker が独自の firewall rules を書き込む方法を説明しています。
Apache と PHP にインストールする場合
リポジトリ内の Documentation/INSTALLATION_INSTRUCTIONS.txt が正式な手順で、全9ステップから成ります。構成は次のとおりです。まず Web サーバー、言語、sandbox を用意します。
sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-all-dev php8.3-zip php8.3-gd bubblewrapphp8.3-* の名前は Ubuntu 24.04 に対応しています。php -v を実行し、使用しているバージョンに対応する prefix を指定してください。パッケージ名は PHP のリリースごとに変わるため、誤った指定では Unable to locate package になります。
次に converter をインストールします。これでドキュメント、画像、音声、動画、OCR に対応できます。実際に必要となる変換の大半をカバーします。
sudo apt install -y imagemagick ffmpeg libreoffice-common libreoffice-java-common \
default-jre ghostscript poppler-utils libgxps-utils tesseract-ocr inkscape \
xvfb clamav curl tar libxcb-cursor0アーカイブ形式、3D モデル、ebook、起動可能な ISO イメージには、これより多くのパッケージが必要です。一部は Ubuntu の multiverse component に含まれています。公式手順のステップ3と5に、必要なパッケージの一覧が順番どおりに記載されています。依存関係のうち2つは apt パッケージではありません。repository には、encoder が必要な場合や、Ubuntu がパッケージ化していない ImageMagick 7 が必要な場合に備えて、Documentation/Build/ffmpeg-build.sh と Documentation/Build/build-imagemagick-v7.sh が用意されています。ebook のサポートは calibre 独自の installer で導入します。手順では次の1行で示されています。
sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdinこれは vendor の script を root として shell に pipe する方法です。upstream が案内する方法ですが、必須ではありません。省略しても、失われるのは ebook 変換だけです。
次に PHP の制限値を設定します。変換には時間がかかり、ファイルも大きいため、標準値では小さすぎます。プロジェクトでは php.ini に次の値を設定します。
max_execution_time = 1200
max_input_time = 90
memory_limit = 512M
post_max_size = 5000M
upload_max_filesize = 5000M
max_file_uploads = 100
display_errors = Off
zlib.output_compression = Onこれらの値は、十分な余裕があるマシンを前提としています。小規模な VPS で使用する場合は、事前に値を下げてください。upload_max_filesize = 5000M と max_file_uploads = 100 の組み合わせでは、1つのリクエストが 40 GB のディスク容量を超えるデータを書き込む可能性があります。Apache を再起動し、PHP が実際に読み込んだ値を確認します。
sudo service apache2 restart
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"次に作業ディレクトリを設定します。Resources/config.php 内の $ConvertLoc がその場所を指定し、デフォルト値は /DATA/HRConvert2 です。Web サーバーのユーザーが、このディレクトリの所有者である必要があります。
sudo mkdir -p /DATA/HRConvert2
sudo chmod -R 0755 /DATA/HRConvert2
sudo chown -R www-data:www-data /DATA/HRConvert2Apache の document root 配下に release を展開します。デフォルトの構成では HRProprietary/HRConvert2 フォルダーに配置されます。Resources/config.php 内の $InstLoc には、実際に配置した場所を指定する必要があります。その後、組み込みの診断機能を実行します。ユーザーが問題に遭遇する前に、不足している依存関係を見つける最も簡単な方法です。
sudo php /path/to/HRConvert2/convertCore.php -v-v は、インストール全体を確認します。core のバージョン、依存関係、sandbox の状態、language pack を調べます。ファイル変換は command line から実行できないため、この引数セットは管理用途に限られます。
新規の Ubuntu 24.04 インストール環境では、なぜすべての変換に失敗するのですか？
サンドボックスが原因です。これは、初日に発生する問題として最も一般的です。Ubuntu 24.04 と Debian 12 では、権限のないユーザーによる user namespace がデフォルトで制限されています。Bubblewrap はサンドボックスの構築に user namespace を必要とするため、bwrap を起動できません。アプリケーションはサンドボックスなしの変換を拒否するため、すべてのジョブが失敗します。
次のコマンドで直接確認します。
bwrap --ro-bind / / --dev /dev /bin/true && echo sandbox okpermission denied エラーが表示された場合、namespace がブロックされています。修正には bwrap バイナリ用の AppArmor プロファイルを使用します。まず ABI ファイルを一覧表示し、存在する中で最大の番号を確認します。
ls /etc/apparmor.d/abi/次に /etc/apparmor.d/bwrap を作成します。4.0 は、その最大番号に置き換えてください。
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}読み込みます。
sudo apparmor_parser -r /etc/apparmor.d/bwrap出力がなければ、プロファイルは読み込まれています。もう一度 bwrap のチェックを実行すると、sandbox ok と表示されるはずです。これで変換が動作します。
インターネットから利用できるコンバーターは、見知らぬ利用者に公開されたパーサーです
このセクションが、この記事の中心です。インターネットから到達できるファイルコンバーターは、匿名の利用者から任意のファイルを受け取り、LibreOffice、ImageMagick、FFmpeg、または Ghostscript に渡します。これらは大規模な C および C++ のコードベースで、長年にわたりパーサーのバグが発見されています。アップロードする利用者が形式を選ぶため、どのパーサーを実行するか、またパーサー内部のどのコードパスを通るかも、その利用者が選ぶことになります。
HRConvert2 は、すべての依存関係を bubblewrap の namespace 内で実行します。各変換処理から見えるディレクトリは2つです。1つは入力を保持するディレクトリで、読み取り専用でマウントされます。もう1つは出力を受け取るディレクトリです。ネットワークは共有されません。プロジェクトの表現では、closes every URL handler in every dependency at once です。この点は、見た目以上に重要です。ImageMagick と Ghostscript は、URL を取得する参照をどちらも受け付けます。そのため、コンバーターが、ネットワーク内部からクラウドのメタデータエンドポイントへ到達するためのサーバーサイドリクエストフォージェリ（SSRF）ツールになることがあります。namespace 内にネットワークがなければ、その取得は実行できません。
拒否動作も同じくらい重要です。A server that cannot build a sandbox refuses the conversion rather than quietly running without one. ログに警告を出すだけのツールより、処理を安全側で停止するツールのほうが信頼できます。そのため、前述の AppArmor の手順は省略できません。また、コンテナを公開する前に $RequireSandboxOnDocker も確認する必要があります。
policy.xml による ImageMagick の強化
ImageMagick 自身の policy ファイルは、サンドボックスの下に置く第 2 層です。設定する価値があります。ImageMagick 6 を使用する Ubuntu 24.04 では、ファイルは /etc/ImageMagick-6/policy.xml にあります。現在有効な設定を表示します。
identify -list policyプロジェクトは Documentation/Build/policy.xml に policy を提供しており、参考になります。PS、PS2、PS3、EPS、XPS、MVG の coder を拒否し、URL、HTTPS、HTTP、gs の delegate も拒否します。一方、PDF は許可します。
<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="delegate" rights="none" pattern="URL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="read|write" pattern="PDF" />重要なのは gs の行です。ImageMagick は PostScript を自身で解析しません。Ghostscript を外部コマンドとして実行します。ImageMagick の既知のリモートコード実行バグは、この delegate に存在します。この delegate を拒否すると、ファイルの内容が何を示していても、ImageMagick はアップロードされたファイルを gs に渡しません。
同じ policy ではリソース上限も設定しています。これにより、細工された 1 つの画像がマシンのリソースを使い果たすことを防ぎます。
<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="width" value="16KP"/>
<policy domain="resource" name="height" value="16KP"/>
<policy domain="resource" name="area" value="128MP"/>decompression bomb は、非常に小さいファイルでありながら、巨大なサイズを宣言します。width、height、area の制限により、メモリ割り当てが行われる前に拒否されます。そのため、カーネルが別のプロセスを強制終了する前に、プロセスが終了します。
逆方向にも注意点があります。Ubuntu の標準 policy は PDF coder を完全に拒否します。そのため、変更していないシステムでは PDF 処理が attempt to perform an operation not allowed by the security policy 'PDF' で失敗します。この文字列は、policy が正常に機能していることを示します。coder を再び許可するかどうかは、意図的に判断してください。その場合も、gs delegate は拒否したままにします。
小規模 VPS で依存関係が必要とするリソース
アイドル状態では、これらに大きなコストはかかりません。Apache と PHP は数十 MB 程度で、変換用バイナリも実行されていないためです。コストが一度に発生するのは、ファイルが配置されたときです。
ドキュメント変換では LibreOffice が起動し、続いて Java ランタイムが起動します。画像変換では、上記のポリシーにより ImageMagick に 256 MiB のメモリと 512 MiB のメモリマップが割り当てられます。動画変換では、FFmpeg が利用可能なすべてのコアを使用します。FFmpeg が動画を処理する際の動作はこれだからです。PHP 自体の memory_limit は、プロジェクトの設定で 512M です。これらの値は、1 つのジョブの実行中に、オペレーティングシステムと Web サーバーの使用量に加算されます。
そのため、1 GB の VPS では最初の本格的なドキュメント処理で swap が発生し、その後スラッシング状態になります。メモリが枯渇すると、kernel の out of memory killer は resident size が最大のプロセスを終了させます。通常は soffice.bin が該当し、ユーザーには有用なメッセージのない変換失敗として表示されます。apache2 が終了すると、サイト全体が停止することもあります。事後には dmesg -T | grep -i "killed process" で確認できます。
これはベンチマークではなく、サイジングの目安です。小規模なチームであれば、RAM 4 GB と 2 コアで余裕があります。負荷がドキュメントと画像中心で、待ち時間を許容できるなら、swap file を用意した 2 GB でも運用できます。swap file によって変換が高速になるわけではありません。バースト的な負荷を致命的な障害ではなく低速な処理に変えられるため、ページの停止とサービス停止の違いになります。ディスクには、必要だと感じる量よりも余裕を持たせてください。3 GB の画像、大きな upload limit、変換後の出力が重なると、他のリソースが枯渇するよりも先にディスクが満杯になるためです。
変換処理は本質的にバースト的です。同時に 2 人が動画を upload すると、すべてのコアが使用され、次のリクエストはその処理が終わるまで待機します。この構成の前段には job queue がないため、制御手段は limits だけです。
ディスクを 1 件のアップロードで使い切らせない制限を設定する
まず PHP の値を下げます。共有の 4 GB サーバーでは、upload_max_filesize = 512M、post_max_size = 512M、max_file_uploads = 20 のような設定が適切な開始点です。max_execution_time = 1200 を設定すると、1 件の PHP リクエストが 20 分間実行できます。長時間の動画変換には実際に必要な時間ですが、遅いアップロードが 1 つのワーカーを 20 分間占有することにもなります。
次に、リクエストが PHP に到達する前に、プロキシでサイズとレートを制限します。
limit_req_zone $binary_remote_addr zone=convert:10m rate=6r/m;
server {
listen 443 ssl;
server_name convert.example.com;
client_max_body_size 512M;
client_body_timeout 300s;
location / {
limit_req zone=convert burst=4 nodelay;
proxy_pass http://127.0.0.1:8080;
proxy_read_timeout 1200s;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}client_max_body_size は、変換する最大ファイルのサイズ以上にする必要があります。そうしないと nginx が 413 Request Entity Too Large を返し、PHP はアップロードを受け取りません。proxy_read_timeout は、最も長い変換時間を超える値にする必要があります。そうしないと、プロキシの背後で正常に実行されているジョブが、ブラウザーに 504 Gateway Time-out を返します。TLS（transport layer security）の終端を含む、その server block の残りの設定については、nginx の reverse proxy 設定を行ごとに解説した記事で説明しています。
変換済みファイルを削除する
変換のたびに、Web サーバーが読み取れるディレクトリへ機密ファイルのコピーが残ります。クリーンアップを行うことで、コンバーターを、これまでに変換したすべてのファイルを保管するアーカイブにしないで済みます。
$DeleteThreshold は、セッションが期限切れになるまでの分単位の時間を Resources/config.php で指定します。デフォルトは 60 です。コンテンツが機密情報を含む場合は、15 に下げます。スイープ自体はコアのコマンドライン引数です。
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c=15-c は、設定されたしきい値を使用して、2 つのデータ保存場所から期限切れのセッションを削除します。-c=15 は、その実行時だけ 15 分を使用します。-c=now は、経過時間に関係なくすべてのセッションを削除します。実行中にユーザーが変換しているセッションも含まれるため、メンテナンス時にだけ使用してください。同じ引数は、docker exec を介してコンテナ内でも使用できます。
誰かがページを読み込むことに依存せず、必ずクリーンアップされるように、スイープをタイマーに登録します。/etc/cron.d/hrconvert2 に次の 1 行を追加するだけで十分です。
*/10 * * * * www-data php /path/to/HRConvert2/convertCore.php -c数分後に ls /DATA/HRConvert2 で確認し、古いセッションディレクトリが消えることを監視します。Web サーバーユーザーがこのディレクトリを所有しているため、パーサーが侵害された場合に取得されるのは、まさにそのアカウントです。そのアカウントには、他の重要なリソースへの所有権を与えないでください。VPS での最小権限ユーザーアカウント が一般的なパターンであり、このケースでは特に重要です。
認証の背後に置く。ただし、公開が目的の場合を除く
デフォルトのインストールでは、設計上アカウントが作成されません。ページに到達できるユーザーは誰でもファイルをアップロードし、変換用バイナリを実行できます。レート制限は処理を遅らせるだけです。まず、自分の状況を判断してください。
自分と数人の同僚だけが使う場合は、外部に公開しないでください。前述のとおりコンテナを loopback にバインドし、プライベートネットワークまたは SSH トンネル経由でアクセスします。これにより、パブリックインターネット上の何者もファイルを送信できなくなります。単に通信を絞り込むのではなく、攻撃対象領域全体をなくせます。
ブラウザーからアクセスできる必要がある場合は、プロキシの前段に認証を配置します。Basic auth は2つのコマンドで設定でき、見知らぬユーザーからアップロードフォームを隠せます。
sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alicelocation / {
auth_basic "Converter";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:8080;
}nginx をリロードしてページを開きます。認証プロンプトが表示されれば機能しています。プロンプトが表示されない場合は、編集した location ブロックがリクエストを処理していません。共有パスワードではなく実際のアカウントを使う場合は、single sign-on プロバイダーで認証を終端します。自己ホスト型の Authentik SSO サーバーを使えば、ログイン機能を持たないアプリケーションの前段に forward authentication を配置できます。
本当に公開されたコンバーターが目的なら、その意味を受け入れて計画してください。サンドボックスが調査されることを前提にします。イメージタグを固定し、ImageMagick のポリシーを厳格に保ち、アップロード制限を小さく設定し、重要なデータを保存していない VPS で実行してください。
障害パターンと表示されるメッセージ
すべての変換が直ちに失敗する。 サンドボックスを構築できません。通常のインストールでは、原因は AppArmor プロファイルです。Docker では、--security-opt seccomp=unconfined がありません。アプリケーションはその状態を A sandbox blocks the required syscalls unless it was started with the correct options. として示し、See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php. を参照します。
画像変換だけが失敗する。 Bubblewrap is missing or non functional, so this image conversion cannot be isolated! は、bwrap が存在しないか、Web サーバーのユーザーが利用できる PATH 上で見つからないことを示します。
1 つの形式だけが失敗し、ほかは動作する。 バイナリが見つからないことを明示するメッセージです: ImageMagick may not be installed, or may not be reachable on the system path used by the web server user. FFmpeg と LibreOffice にも同じ形式のメッセージがあります。convertCore.php -v を実行して、インストールから検出できるものを確認してください。Apache worker の PATH は、ログインシェルの PATH とは異なることに注意してください。
PDF 処理がポリシーエラーで失敗する。 attempt to perform an operation not allowed by the security policy 'PDF' は HRConvert2 ではなく、ImageMagick の policy.xml に起因します。
大きなアップロードで 413 が返る。 nginx の client_max_body_size がファイルサイズを下回っています。この処理経路には、nginx に 1 つ、PHP に 2 つの計 3 つの制限があり、最も小さい値が適用されます。
変換が停止し、明らかな変更もない。 The device where data is stored has an insufficient amount of storage space available. 空き容量を確認し、クリーンアップ処理が実際に実行されていることを確認してください。
クリーンアップに関するメッセージがログに出る。 Could not clean the temporary location! と Could not clean the convert location! は所有権の問題です。Web サーバーのユーザーが $ConvertLoc で指定されたディレクトリを所有している必要があります。
FAQ
自分でホストするファイル変換サーバーをインターネットに公開しても安全ですか？
見知らぬ利用者に公開するパーサーとして扱う場合に限り、十分安全です。アップロードされたファイルはすべて LibreOffice、ImageMagick、FFmpeg、Ghostscript のいずれかに渡され、使用するツールはアップロードした利用者が選択します。HRConvert2 は、これらのツールをネットワーク接続なし、かつ入力ディレクトリを読み取り専用にした bubblewrap の namespace 内で実行します。また、sandbox 化できない変換は拒否します。これは安全性を重視した適切なデフォルト設定です。それでも、認証を必須にし、アップロード上限を小さく設定し、重要なデータを保管していない VPS で実行する方が安全です。
新規に Ubuntu 24.04 をインストールすると、すべての変換が失敗するのはなぜですか？
Ubuntu 24.04 と Debian 12 は、権限のない user namespace を制限しています。bubblewrap は sandbox の構築に user namespace を必要とします。アプリケーションは sandbox なしの変換を拒否するため、一部のジョブではなく、すべてのジョブが失敗します。/usr/bin/bwrap 用の AppArmor profile を flags=(unconfined) で作成し、sudo apparmor_parser -r /etc/apparmor.d/bwrap で読み込んでから、bwrap --ro-bind / / --dev /dev /bin/true で確認してください。
Docker では変換に失敗するのに、通常のインストールでは動作するのはなぜですか？
Docker のデフォルト seccomp profile が bubblewrap の使用する system call をブロックするため、コンテナ内に sandbox を作成できません。プロジェクト独自の実行コマンドと同じ --security-opt seccomp=unconfined を指定して起動してください。$RequireSandboxOnDocker はデフォルトで FALSE です。そのため、フラグを指定しないコンテナでは sandbox なしで変換されることがあります。seccomp フラグを設定したら、$RequireSandboxOnDocker を TRUE にしてください。
ファイル変換サーバーにはどの程度の RAM が必要ですか？
アイドル時の使用量は少ないですが、変換中は少なくありません。LibreOffice は Java runtime を起動します。ImageMagick は、提供された policy の設定で 256 MiB のメモリと 512 MiB の map を使用します。PHP 自体の上限も 512M です。1 GB の VPS では、この組み合わせにより swap が発生し、out of memory killer が soffice.bin または apache2 を終了させます。小規模なチームでは 4 GB と 2 コアを計画し、メッセージなしで変換が終了した場合は dmesg -T | grep -i "killed process" を確認してください。
変換済みファイルはどこに保存され、いつ削除されますか？
Resources/config.php の $ConvertLoc で指定された作業ディレクトリに保存されます。デフォルトは /DATA/HRConvert2 です。$DeleteThreshold はセッションが期限切れになるまでの時間を分単位で設定し、デフォルトは 60 です。削除処理はコマンドラインから実行します。php convertCore.php -c は期限切れのセッションを削除し、-c=now はアクティブなセッションを含むすべてのセッションを直ちに削除します。サイトへのアクセスに削除処理を依存させないよう、-c を cron エントリまたは systemd timer に設定してください。