Den ursprungliga installationen av Paperless-ngx misslyckades sent i ZimaOS App Store-processen, först med ett obehörighetsfel när en Tika-avbildning hämtades från GitHub Container Registry och senare med ett DNS-fel för en registerspegel. Den kombinationen gör tråden mer komplicerad än att säga att ”Paperless är trasigt”: den felande komponenten var en valfri Tika-tjänst/avbildningssökväg, och registeradressen ändrades mellan försöken.
Den offentliga tråden nådde aldrig fram till en bekräftad lösning för ZimaOS App Store. En användare bytte Tika-avbildningen till Apaches avbildning och nådde 100 % installation, men stacken kördes fortfarande inte. Den aktuella dokumentationen för Paperless-ngx erbjuder nu en tydligare väg: använd de underhållna Docker Compose-mallarna och aktivera Tika/Gotenberg-varianten endast när dessa dokumentformat behövs.
Det första felet var ett GHCR-auktoriseringsfel
Det ursprungliga felet inträffade runt 80 %:
Head "https://ghcr.io/v2/paperless-ngx/tika/manifests/2.9.1-minimal": unauthorizedAtt ta bort lokala Docker-avbildningar och installera om ändrade inte resultatet, vilket talar emot att det handlade om en enkel gammal lokal avbildning.
Nästa försök misslyckades vid DNS-upplösningen
Två dagar senare hade felet ändrats till en misslyckad DNS-sökning för ett värdnamn till en registerspegel. En person i communityn föreslog därför att kontrollera namnupplösning, grundläggande HTTPS-anslutning, DNS-filtrering, VPN-/proxybeteende och en manuell hämtning av avbildningen.
Detta var felsökningsförslag från communityn, inte en rotorsak som bekräftats av IceWhale.
Tika är valfritt i den aktuella versionen av Paperless-ngx
Den aktuella dokumentationen för Paperless-ngx anger att Tika och Gotenberg är valfria tjänster som används för Office-dokument som DOC/XLSX/ODT och för e-posttolkning. Om dessa format inte behövs behöver Tika inte aktiveras alls.
Om de behövs bör du använda den underhållna Compose-varianten som inkluderar Tika och Gotenberg i stället för en gammal appbutiksreferens till en avbildning.
Den aktuella Docker Compose-konfigurationen från upstream är den bästa utgångspunkten
Den aktuella installationsguiden för Paperless-ngx rekommenderar Docker för de flesta användare och tillhandahåller underhållna Compose-filer. För nya installationer rekommenderas PostgreSQL, och mallar med Tika tillhandahålls separat.
Använd den aktuella installationsmodellen för Paperless-ngx med Docker Compose om ZimaOS App Store-paketet är föråldrat eller hänvisar till en otillgänglig hjälpavbildning.
Att bara byta Tika-avbildningen kanske inte räcker
En deltagare ersatte Tika-avbildningen med apache/tika:latest. Installationen nådde 100 %, men programmet misslyckades fortfarande efter uppstart.
Det negativa resultatet är viktigt eftersom Paperless kräver att tjänstens slutpunkt, funktionsflagga och Gotenberg-integrering överensstämmer med Compose-konfigurationen. Ett byte av containeravbildning är inte nödvändigtvis en fullständig migrering av stacken.
Placera Paperless beständiga data på huvudlagringsutrymmet
Paperless kan växa genom importerade dokument, miniatyrbilder, OCR-data, sökindex och databasen. Den aktuella dokumentationen för ZimaOS rekommenderar att appdata flyttas från systemenheten innan lagringskrävande program installeras.
Den aktuella modellen för app-lagringssökvägar i ZimaOS är särskilt relevant för Paperless eftersom dess dataavtryck kan växa långt utöver Docker-avbildningens storlek.
Behörigheter är viktiga för konsumtionsmappen
Den aktuella dokumentationen för Paperless-ngx exponerar USERMAP_UID och USERMAP_GID så att containern kan skriva till bind-monterade mappar på värddatorn. Om stacken installeras men inte kan importera dokument bör du kontrollera dessa värden och behörigheterna för mapparna på värddatorn i stället för att återgå till felsökning av registret.
Betrakta inte ett värdnamn för en registerspegel som själva Paperless-programmet
Det andra källfelet hänvisade till ett värdnamn som liknade en spegel i stället för huvudslutpunkten ghcr.io. Den skillnaden är viktig: ett programpaket kan vara helt giltigt medan den konfigurerade avbildningsspegeln, DNS-servern eller den regionala registersökvägen är otillgänglig.
Om en manuell hämtning från upstream-registret lyckas men App Store fortfarande försöker använda en trasig spegel, hör problemet till paket- eller registerdirigeringslagret och inte till Paperless självt.
Skilj på fel vid hämtning av avbildningar och fel vid uppstart av containrar
Det första försöket från källan slutförde aldrig hämtningen av alla obligatoriska avbildningar. Det senare experimentet med Apache Tika nådde 100 % installation men misslyckades sedan efter uppstart. Detta är två olika felstadier som kräver olika underlag.
- Hämtningsstadiet: registerautentisering, DNS, spegeltillgänglighet och avbildningstagg.
- Uppstartsstadiet: miljövariabler, databasanslutning, Tika-/Gotenberg-slutpunkter, volymer, behörigheter och hälsokontroller.
Säkerhetskopiera en fungerande Paperless-instans innan du ersätter App Store-stacken
Om Paperless redan används bör du inte byta Compose-mallar enbart för att åtgärda en hjälpservice utan att först skydda dokumenten och databasen. Den aktuella versionen av Paperless från upstream innehåller ett exportverktyg särskilt för säkerhetskopiering och migrering.
För en ny installation är det enklare att börja med den underhållna Compose-filen från upstream. För en befintlig installation bör du bevara de aktuella databas- och mediesökvägarna innan stacken skrivs om.
Vanliga frågor om installation av Paperless-ngx
Var felet 2025 entydigt ett DNS-problem?
Nej. Tråden visade både auktoriserings- och DNS-fel, och ingen officiell slutlig diagnos publicerades.
Krävs Tika för varje Paperless-ngx-installation?
Nej. Tika är valfritt och behövs främst för Office-dokument och e-posttolkning.
Löste bytet till apache/tika problemet i källfallet helt?
Nej. En användare nådde 100 % installation, men programmet kördes fortfarande inte.
