この2025年12月のチュートリアルは、ZimaOS上のPaperless-ngxに関する、より詳細なコミュニティガイドの一つですが、特定のBigBearパッケージとZimaOS 1.5.3 Plusに結び付いています。長期的に有用な部分は、ストレージと設定に関する概念です。consumeフォルダーに明確で永続的な場所を割り当て、アプリケーションURLを正しく設定し、OCR言語を構成し、オプションのTika/Gotenbergサービスについて理解することです。
いくつかのソースの詳細には、現在の前提条件を示す必要があります。Paperless-ngxの公式Dockerセットアップは進化しており、新規インストールではPostgreSQLが推奨されています。現在のComposeファイルでは初回セットアップ時にスーパーユーザーの作成が求められ、Tika/Gotenbergはすべてのドキュメントワークフローで必須ではなく、引き続きオプションです。
このソースチュートリアルは、比較的小規模なZimaBoard 2でテストされました
著者は、16 GBのRAMを搭載したN150ベースのシステムで、ZimaOS 1.5.3 Plusを実行しました。目的は家庭でのローカルネットワークまたはTailscale経由のアクセスであり、直接の公開は想定していません。
この範囲は重要です。公開インターネット環境での導入には、異なるHTTPS、リバースプロキシ、認証、セキュリティ計画が必要になります。
このガイドではBigBear Paperless-ngxのカスタムインストールを使用しました
ソースの手順では、App StoreでBigBear Paperless-ngxパッケージを検索し、インストールのドロップダウンを開いてカスタムインストールを選択し、初回起動前にボリュームと環境値を編集しました。
これはパッケージ固有の手順です。現在のアプリ定義では、サービスや変数の追加、削除、名前変更が行われる可能性があります。
Consumeディレクトリに明確で永続的なホストパスを設定する
/usr/src/paperless/consume ユーザーがドキュメントを投入する際に操作する可能性が最も高いフォルダーとして。現在のPaperless公式ドキュメントでも、引き続き次の場所が使用されています /usr/src/paperless/consume 標準のコンテナ側のパスとして指定されており、このバインドマウントのホスト側を変更することも明示的にサポートしています。
このチュートリアルでは、管理者、コンシューマー、OCR、URLの変数を設定しました
主なソース選択項目：
- カスタム管理者ユーザー名／パスワード。
- ドキュメントの再帰的な取り込み。
- 取り込み成功後にconsumeフォルダーから原本を削除する設定。
- OCRのクリーンアップと言語設定。
- CSRFで信頼するオリジンとアプリケーションURL。
- Tika/Gotenbergエンドポイント。
PAPERLESS_URLとCSRFオリジンは、Paperlessへの実際のアクセス方法に合わせる必要があります
このチュートリアルでは、URLまたはオリジンの設定が正しくないと、403 CSRF検証エラーが発生する可能性があると警告していました。この点は、概念的には現在も正しいです。
現在のPaperlessのドキュメントには、次のように記載されています PAPERLESS_URL アプリケーションをリバースプロキシの背後で使用する場合に設定し、外部から使用するドメインまたはURLを指定する必要があります。情報源の執筆者のLANアドレスを別のインストール環境にハードコードしないでください。
OCR設定もPaperless内で調整
OCR言語は、コンテナで利用可能な言語パックに対応している必要があります。言語を追加すると、現在のパッケージによってはイメージサイズが増加したり、rootlessコンテナの要件が変わったりする場合があります。
大量のconsumeバッチ後に毎回再起動するのは、情報源の助言であり、アップストリームの要件ではない
現在のPaperless-ngxは、consumeディレクトリを継続的に監視するよう設計されています。アップストリームのドキュメントには、大量のバッチ処理で通常再起動が必要になるとは記載されていません。文書の処理が停止した場合は、再起動を必須の手順にするのではなく、権限、コンシューマーのログ、ファイルシステムの通知サポート、ブローカーやワーカーの状態を確認してください。
新規インストールには現在のアップストリーム設定でPostgreSQLを推奨
現在のPaperless-ngxのDockerセットアップでは、新規インストールにPostgreSQLが推奨されていますが、サポート対象の構成ではSQLiteとMariaDBも引き続き利用できます。
長期的な文書アーカイブでは、現在のアップストリームComposeトポロジーを、BigBearの2025年のデータベースサービスがそのまま残っていると想定するよりも、優れた参考情報として扱えます。
TikaとGotenbergはオプション
現在のPaperlessのドキュメントでは、DOC/XLSX/ODTなどのOffice文書やメールファイルを解析するには、TikaとGotenbergが必要とされています。Paperlessコアスタックで処理できる形式のみを取り込む場合は、この機能を無効のままにできます。
手動で過去のBigBearスタックを再構築する前に、現在のPaperless-ngx Dockerセットアップを使用してください。
消費フォルダーの権限は、再起動を繰り返すことよりも重要
現在のアップストリーム設定では USERMAP_UID および USERMAP_GID コンテナがホストのバインドマウントに書き込めるようにするためです。Paperlessがconsumeフォルダーを認識してもファイルを処理または削除できない場合は、マッピングされたディレクトリの所有権とコンテナの実行ユーザーを確認してください。
ZimaOSでは、ホスト側のconsumeパスが意図した管理ストレージ上にあり、読み取り専用のボリュームマッピングではないことも確認してください。
/consumeからのオリジナル削除は、アーカイブ済みドキュメントの削除とは異なります
原文では有効にしていました PAPERLESS_CONSUMER_DELETE_ORIGINALS=true。これは、正常な取り込み後にconsumeディレクトリ内の入力ファイルをどう処理するかを制御します。Paperlessが管理するアーカイブ済みドキュメントは、引き続きメディアストレージに保存されます。
自動スキャナーや同期サービスを本番フォルダーに接続する前に、使い捨てのドキュメントでこの動作をテストしてください。
Paperless-AIに関する返信は別の統合に属します
後続の返信では、Paperless-AIがPaperless API経由でドキュメントを読み取れる一方、組み込みのOpenAI設定ではタグの分析や書き込みに失敗する問題が説明されました。ユーザーからは、Mistralは動作し、OpenAIを手動で設定すると問題を回避できるとの報告がありました。
これらの返信は、Paperless-ngxの中核インストールが壊れていることを証明するものではありません。Paperless-AIは独自のプロバイダー/API設定を持つ、別のサードパーティー製統合です。
後発の500エラーとパスワードに関する質問は、スレッド内では解決されていません
2026年2月のユーザーはアップロード中にHTTP 500が発生したと報告し、2026年5月のユーザーは想定されたパスワードでログインできませんでした。公開スレッドには、これらのケースの最終的な診断は記載されていません。
元のチュートリアルにある例示用の認証情報を、後続のBigBearリリース向けの普遍的なログイン手順にしないでください。
大規模なパッケージ変更の前にPaperlessデータをエクスポートする
現在のPaperlessには、移行やバックアップのワークフロー向けに、ドキュメント、サムネイル、メタデータ、データベース由来の情報を含むドキュメントエクスポーターがあります。データベースやComposeスタックを置き換える前に、アプリケーション対応のエクスポートと通常のストレージバックアップを併用してください。
ZimaOS上のPaperless-ngx FAQ
すべてのPaperless-ngxインストールでTikaは必須ですか？
いいえ。任意であり、主にOfficeドキュメントやメールの解析に必要です。
大量のconsumeバッチでは、通常、再起動が必要ですか？
原文の著者は自身の経験からそれを推奨していましたが、現在の上流ドキュメントでは、再起動を通常必要な手順とはしていません。
現在のPaperlessでは、新規インストールにどのデータベースを推奨していますか？
新しいDockerデプロイメントでは、PostgreSQLが推奨バックエンドです。
Paperless-AIはPaperless-ngx自体の一部ですか？
いいえ。これはスレッドの後半で説明されている、別のサードパーティー製統合です。
