Felsökning

Börja med lagret som felar: webbläsare, frontend, backend, Ollama, leverantörsplugin eller driftsättningens nätverk.

Snabbkontroller

# App branch and local changes
git status

# Backend process liveness
curl http://localhost:3001/health/live

# Backend dependency readiness (SQLite, schema, and writable data storage)
curl http://localhost:3001/health/ready

# Ollama health
curl http://localhost:11434/api/tags

# Installed Ollama models
ollama list

I utvecklingsmiljön körs frontend vanligtvis på http://localhost:5173 och backend på http://localhost:3001. Den paketerade körningen via npx libre-webui tillhandahåller appen på http://localhost:8080.

Libre WebUI startar inte

Kontrollera Node och beroenden

node --version
npm install
npm run dev

Node.js 22.22 eller senare krävs.

Porten används redan

lsof -i :3001
lsof -i :5173
lsof -i :8080

Stoppa den gamla processen eller konfigurera en annan port.

Backend kan inte skriva data

Backend lagrar data under DATA_DIR när variabeln är angiven, annars under backend/data. Vid start från källkod tolkas en relativ DATA_DIR från backend-katalogen, inte från skalets aktuella katalog. Därför väljer DATA_DIR=./data sökvägen backend/data, medan den historiskt stödda DATA_DIR=./backend/data väljer backend/backend/data. Kontrollera att den valda katalogen är skrivbar. Om DATA_DIR inte är angiven behåller Libre den historiska katalogen när den är det enda befintliga datalagret. Om båda platserna innehåller data ska du stoppa Libre, säkerhetskopiera båda och sedan medvetet välja eller migrera. Libre slår aldrig ihop eller kopierar databaser som har utvecklats åt olika håll.

Hälsokontrollernas slutpunkter skiljer avsiktligt mellan en process som körs och en användbar applikation:

• /health och /health/live svarar med 200 så länge backend-processen kan hantera HTTP. Valfria modellleverantörer påverkar inte livsstatusen.
• /health/ready svarar med 503 när en nödvändig databas, ett schema, en lagringsplats eller ett registrerat plattformsberoende inte är tillgängligt. Slutpunkten väntar inte på valfria modellleverantörer. Det offentliga svaret utelämnar felmeddelanden och interna detaljer.
• /health/deep utför integritets- och främmandenyckelkontroller i SQLite via en worker med fasta gränser och sammanställer valfria leverantörskontroller på servernivå, till exempel för Ollama. Ett avbrott hos en valfri leverantör visas som en varning och gör inte nödvändiga beroenden otillgängliga. Slutpunkten kräver en aktuell administratörs bearer-token och lämpar sig inte för täta kontroller från en orkestrerare.

curl -H "Authorization: Bearer $LIBRE_ADMIN_TOKEN" \
  http://localhost:3001/health/deep

Webbläsaren når inte backend

Vid lokal utveckling använder frontend VITE_API_BASE_URL när variabeln är angiven och återgår annars till utvecklingsmiljöns backend.

Exempel på .env för frontend:

VITE_API_BASE_URL=http://localhost:3001/api
VITE_WS_BASE_URL=ws://localhost:3001

VITE_WS_BASE_URL är valfri, men när den anges används den som gemensam basadress för terminalsocketar i Chat och Work. Använd en absolut URL med ws: eller wss:. Ett sökvägsprefix som i wss://example.com/libre stöds. Ta inte med autentiseringsuppgifter, frågeparametrar eller fragment. Starta om eller bygg om frontend efter att du har ändrat en Vite-variabel.

Exempel på .env för backend:

CORS_ORIGIN=http://localhost:5173,http://127.0.0.1:5173

För åtkomst från en telefon, ett lokalt nätverk eller Tailscale ska du inte låta telefonens webbläsare ansluta till localhost. Använd den bärbara datorns IP-adress i det lokala nätverket eller Tailscale och kör utvecklingsservern med värdbindning:

npm run dev:host

Detta serverar frontend på port 8080 och vidarebefordrar API- och WebSocket-trafik till den lokala backend-en på port 3001. Endast port 8080 behöver vara nåbar från den andra enheten. Om VITE_API_BASE_URL eller VITE_WS_BASE_URL är angivna i frontend/.env, se till att dessa URL:er är nåbara från den andra enheten, eller ta bort dem för att använda utvecklingsserverns proxy.

Chatten strömmas inte bakom en omvänd proxy

Det typiska symptomet är att meddelanden skickas men att inget svar visas, samtidigt som webbläsarkonsolen visar att WebSocket-anslutningen misslyckas. Kontrollera att proxyn tillåter WebSocket-uppgraderingar och inte stänger långlivade anslutningar.

När något av värdena är konfigurerat kontrolleras webbläsaruppgraderingar som skickar ett Origin-huvud mot CORS_ORIGIN och BASE_URL. Ange minst ett av dem för en fjärrdriftsättning. Om inget av dem är konfigurerat förblir Origin-filtret tillåtande för lokal utveckling. Electron och andra klienter som inte är webbläsare kan utelämna Origin, men de måste ändå först byta sitt Authorization-huvud mot en kortlivad engångsbiljett. Håll backend bakom TLS och samma nätverks- eller proxyåtkomstkontroller som används för HTTP-API:t.

För ett offentligt värdnamn ska du tillåta detta webbläsarursprung i Libre WebUI-tjänsten:

services:
  libre-webui:
    environment:
      CORS_ORIGIN: https://chat.example.com
      BASE_URL: https://chat.example.com

Exemplen för nginx och Caddy nedan förutsätter att proxyn körs på Docker-värden, där repots Compose-konfiguration publicerar Libre WebUI på port 8080. Om proxyn i stället ansluter till Compose-nätverket använder du libre-webui:3001 som uppströmsadress.

nginx

nginx kräver att uppgraderingshuvudena vidarebefordras uttryckligen. Den längre lästimeouten håller en annars inaktiv chattanslutning öppen medan modellen arbetar.

location /ws {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

Läs in nginx på nytt efter att du har validerat konfigurationen med nginx -t.

Caddy

Caddys reverse_proxy har inbyggt stöd för WebSocket, så inga uppgraderingshuvuden behövs:

chat.example.com {
    reverse_proxy 127.0.0.1:8080
}

Traefik

Traefik hanterar också WebSocket-uppgraderingar som standard. När dess Docker-leverantör delar Libre WebUIs nätverk behövs bara de vanliga etiketterna för router och tjänst, till exempel:

labels:
  - 'traefik.enable=true'
  - 'traefik.http.routers.libre-webui.rule=Host(`chat.example.com`)'
  - 'traefik.http.routers.libre-webui.entrypoints=websecure'
  - 'traefik.http.routers.libre-webui.tls=true'
  - 'traefik.http.services.libre-webui.loadbalancer.server.port=3001'

Om strömmarna ansluter men bryts senare ska du kontrollera inaktivitetstimeouten för eventuella proxyservrar eller lastbalanserare framför Traefik. Om Traefik självt tillämpar gränsen justerar du inställningen transport.respondingTimeouts för ingångspunkten.

Ollama identifieras inte

Kontrollera att Ollama körs

curl http://localhost:11434/api/tags

Konfigurera en egen Ollama-URL

.env för backend:

OLLAMA_BASE_URL=http://localhost:11434

Om Libre WebUI körs i Docker och Ollama körs på värden använder du Compose-filen för extern Ollama eller låter OLLAMA_BASE_URL peka på den värdadress som kan nås från containern.

Problem med modellhämtning

Hämta först från terminalen

ollama pull gemma4:12b

Om hämtningen från terminalen misslyckas ligger problemet utanför Libre WebUI.

Molnmodeller

Använd molnfiltret i Model Manager för Ollama Cloud-modeller. Libre WebUI normaliserar nödvändiga molnsuffix i detta flöde, så användarna ska inte behöva lägga till :cloud manuellt för de molnposter som stöds.

En användare kan inte hämta modeller

Administratörer kan inaktivera modellhämtning för vanliga användare. Kontrollera administratörsinställningarna om en användare som inte är administratör kan bläddra bland modeller men inte installera dem.

Chatten är långsam eller misslyckas

• Använd en mindre modell.
• Kontrollera inlästa modeller med ollama ps.
• Minska kontextlängden.
• Minska det maximala antalet token för mycket långa svar.
• Kontrollera att modellen ryms i RAM/VRAM.
• Kontrollera API-nyckeln och leverantörskvoten för leverantörsplugin.

OpenAI-bildgenerering är inte tillgänglig

• Aktivera den medföljande OpenAI-leverantören. Spara en API-nyckel för den aktuella användaren eller konfigurera den betrodda medföljande leverantörens reservvärde från miljövariabeln OPENAI_API_KEY.
• Öppna inställningarna för Image Generation, aktivera bildgenerering och välj en av de GPT Image-modeller som visas.
• Föredra gpt-image-2. De äldre GPT Image-ID:na finns endast kvar för kompatibilitet med befintliga konfigurationer och är utfasade hos leverantören.
• Lämna OpenAI-åsidosättningen image_endpoint tom om du inte driver en kompatibel bildslutpunkt. En Chat-slutpunkt för /responses eller /chat/completions kan inte hantera förfrågningar till Image API.
• Om OpenAI avvisar en GPT Image-förfrågan trots en giltig nyckel och tillgänglig kvot kontrollerar du att API-organisationen har behörighet att använda GPT Image-modeller.

Bildtillgängligheten utvärderas med den aktuella användarens sparade autentiseringsuppgift eller den betrodda medföljande leverantörens reservvärde från miljön. En nyckel som endast har sparats i en annan användares inställningar gör inte bildmodeller tillgängliga.

Problem med leverantörsslutpunkter

Om en OpenAI-kompatibel leverantör tar emot förfrågningar på fel sökväg kontrollerar du dess inställningar under Settings → Plugins:

• Välj Chat Completions för nyttolaster till /chat/completions eller Responses för nyttolaster till /responses.
• Ange API-roten, till exempel https://provider.example/v1, som bas-URL.
• Lämna API Path tom för lägets standardsökväg eller ange en sökväg från leverantören som inleds med ett snedstreck.
• En faktiskt anpassad äldre fullständig slutpunkt har avsiktligt högst prioritet. Töm den därför när du byter tillbaka till Base URL och API Path. Sparade värden som endast motsvarar det medföljande manifestets gamla standardvärde ignoreras automatiskt efter en uppgradering. När en anpassad slutpunkt slutar med /chat/completions eller /responses avgör suffixet även förfrågningsformatet, så att en åsidosättning inte kan ta emot fel nyttolast.

Importerad plugin-JSON stöder leverantörer som använder ett protokollformat kompatibelt med OpenAI Chat Completions, OpenAI Responses, Anthropic eller Gemini. Om leverantören använder ett eget format för nyttolast, strömningshändelser, verktygsanrop eller svar behövs en backend-adapter. Det räcker inte att ändra slutpunkten för att översätta formatet.

Leverantörs-URL:er får använda HTTP eller HTTPS. HTTP skickar autentiseringsuppgifter och leverantörstrafik utan transportkryptering, så reservera det för en egen driftad gateway i ett betrott nätverk och föredra HTTPS när TLS finns tillgängligt. Bas-URL:er får inte innehålla frågesträngar eller fragment, och relativa API-sökvägar får inte innehålla bokstavliga eller upprepat kodade navigeringssegment, frågesträngar eller fragment. Alltför djup kodning avvisas om den inte stabiliseras inom valideringens begränsade antal steg.

Vid modelluppdatering ersätts kända operationssuffix, inklusive /responses, med /models. Aktivering, uttrycklig uppdatering och sparade anslutningsåsidosättningar använder den aktuella användarens slutpunkt och API-nyckel. Även när användarens API-nyckel sparas eller tas bort och när anslutningsåsidosättningar återställs uppdateras listan, men orelaterade genereringsparametrar gör det inte. Identifierare som hittas lagras per användare och skriver aldrig över den delade plugin-JSON-filen. Om leverantören inte stöder den härledda rutten konfigurerar du modell-ID:n manuellt i pluginets model_map.

Leverantörsförfrågningar följer avsiktligt inte HTTP-omdirigeringar. Det gäller bland annat modellidentifiering, Chat, Work, bildgenerering, inbäddningar och text-till-tal. Konfigurera den slutliga mål-URL:en i stället för en URL som omdirigerar. Det stängda säkerhetsbeteendet hindrar ett Authorization-huvud från att följa med till ett mål som inte har validerats.

Om Work rapporterar att leverantörsdirigeringen ändrades under en körning ska du slutföra uppdateringen av leverantörsinställningarna och sedan starta en ny körning. Work stoppar avsiktligt före nästa leverantörsförfrågan, så att tidigare verktygstillstånd inte kan spelas upp mot ett annat läge, en annan slutpunkt eller en annan autentiseringsgräns för API-nyckeln.

Förfrågningarna kommer från backend, så localhost avser Libre WebUI-containern när backend körs i en container och inte automatiskt värddatorn. För en driftsättning med Compose eller Kubernetes använder du gatewayens DNS-namn för tjänsten, till exempel http://ai-gateway:8080/v1. Använd endast http://host.docker.internal:8080/v1 när containerns körmiljö tillhandahåller det värdaliaset. HTTP-trafik är klartext även när namnet löses internt.

Även bildmodellernas tillgänglighet, åsidosättningar av slutpunkter och API-nycklar fastställs för den aktuella användaren. Om en bildförfrågan verkar använda en annan användares leverantörsinställningar kontrollerar du att förfrågan är autentiserad som den förväntade användaren.

Följande säkerhets- och ägarskapsregler gäller också:

• Logga in som administratör för att ändra leverantörsdirigeringen. Plugindefinitioner och anslutningsfält är konfiguration som hanteras på instansnivå. Vanliga användare kan fortfarande spara genereringsinställningar, autentiseringsuppgifter och sitt eget aktiveringstillstånd.
• När du använder den äldre åsidosättningen endpoint eller api_url anger du den fullständiga URL:en till API-slutpunkten, inklusive operationssökvägen (till exempel https://provider.example/v1/chat/completions). Ange endast en API-rot i base_url, tillsammans med api_mode och eventuellt api_path.
• Absoluta URL:er för HTTP- och HTTPS-slutpunkter godtas. Använd endast HTTP för en egen driftad gateway i ett betrott nätverk, eftersom API-nycklar, promptar och svar annars skickas utan transportkryptering.
• En tom åsidosättning använder slutpunkten som ingår i plugindefinitionen. En uttryckligen felaktig eller osäker åsidosättning avvisas. Libre WebUI skickar inte förfrågan tyst till den medföljande leverantörsslutpunkten.
• En miljönyckel för driftsättningen används endast när en medföljande definition som inte är överskuggad behåller sin betrodda rotslutpunkt, sina autentiseringsfält, förmågeslutpunkter och väljare samt standardvärden för dirigeringsvariabler. Importerade definitioner, skrivbara definitioner som återanvänder ett medföljande ID och anpassade rutter som sparats av en administratör kräver en autentiseringsuppgift som sparats av samma konto. Libre WebUI rapporterar avsiktligt leverantören som otillgänglig och hoppar över identifieringen om endast miljönyckeln finns.
• Anpassade definitioner från tiden före uppgraderingen sätts i karantän, eftersom äldre versioner inte registrerade administratörens ursprung. Importera JSON-filen på nytt som administratör och låt sedan varje användare aktivera den igen. Om en godkänd plugin-JSON redigeras direkt sätts den åter i karantän. Använd administratörsflödet för installation eller uppdatering så att källsökvägen och definitionens hash registreras.
• Sparade autentiseringsuppgifter binds till den rutt, det autentiseringskontrakt, den definition och den källa som gällde när de angavs. När du har ändrat en slutpunkt eller definition sparar du kontots autentiseringsuppgift igen. En gammal obunden autentiseringsuppgift migreras automatiskt endast på en exakt förankrad medföljande rutt.
• Importerade plugin kan använda api_url som ett äldre alias för den fullständiga operations-URL:en. endpoint har företräde när båda fälten är angivna. Om modellidentifieringen finns någon annanstans anger du den fullständiga URL:en för modellistan i models_endpoint. Den valideras och omdirigeringar följs inte.
• Aktivera pluginet efter att du har sparat dess slutpunkt och autentiseringsuppgift. Vid aktiveringen härleds en /models-URL från den sparade fullständiga slutpunkten, och den aktiverande användarens autentiseringsuppgift används för identifieringen om models_endpoint inte är angiven. När något av dessa anslutningsfält sparas eller återställs uppdateras även identifieringen. Förfrågan väntar på identifieringen innan gränssnittet läser in pluginlistan på nytt. Aktiveringen är kontospecifik, så en annan användare måste aktivera samma delade plugin separat.
• Under Settings → Plugins väljer du leverantören och sedan Refresh models för att uttryckligen kontrollera dess katalog. Modelltabellen är skrivskyddad och visar de ID:n som är konfigurerade eller identifierade för det aktuella kontot. Vid ett tillfälligt identifieringsfel behålls den föregående identifierade katalogen, eller pluginets reservvärde model_map om inget tidigare resultat finns. En slutförd kontroll bevisar därför inte i sig att fjärrslutpunkten fungerar.
• Automatisk identifiering kräver en OpenAI-kompatibel data-matris med modell-ID:n. Kataloger som har hämtats sparas per användare utan att den delade plugin-JSON-filen ändras. En normal aktivering behåller användarens tidigare katalog när identifieringen inte är tillgänglig. Om ett anslutningsfält ändras eller återställs rensas först den inaktuella katalogen, så en misslyckad uppdatering använder pluginets befintliga model_map. Konfigurera vid behov dessa reserv-ID:n för modeller i plugin-JSON-filen.
• Även bildmodellernas tillgänglighet, åsidosättningar av slutpunkter och API-nycklar fastställs för den aktuella användaren. Om en bildförfrågan verkar använda en annan användares leverantörsinställningar kontrollerar du att förfrågan är autentiserad som den förväntade användaren.
• Om ett uppgraderat konto som inte tillhör en administratör tidigare har sparat ett dirigeringsvärde använder du Reset för detta plugin. Det ignorerade äldre värdet tas bort så att det inte kan bli aktivt efter en senare rolländring. När dirigeringen sparas eller återställs rensas också kontots identifierade modeller, så att en inaktuell katalog inte kan följa med den gamla rutten.
• Förfrågningarna kommer från backend. När Libre WebUI körs i en container avser localhost containern, inte automatiskt värddatorn.
• Leverantörsförfrågningar följer inte omdirigeringar. Konfigurera den slutliga validerade operations-URL:en direkt.

Chatten använder fel leverantör eller visar den som otillgänglig

Samma modell-ID kan finnas i Ollama och i fler än ett plugin. Aktuella Chat-sessioner och inställningar för standardmodell sparar både den valda leverantören och det ursprungliga modell-ID:t. Poster med liknande namn är därför oberoende val.

• Om väljaren anger att en leverantör inte är tillgänglig ska du aktivera eller installera om just detta plugin och kontrollera att dess modellmappning fortfarande innehåller det sparade modell-ID:t.
• Om leverantören eller modellen togs bort avsiktligt väljer du uttryckligen en ersättare. Libre WebUI dirigerar inte om ett exakt sparat val till en modell med samma namn hos en annan leverantör.
• Äldre sessioner och inställningar kan sakna leverantörsmetadata. Dessa poster fortsätter att använda äldre dirigering som enbart bygger på namn, eftersom Libre WebUI inte kan avgöra vilken leverantör som ursprungligen avsågs. I modellväljarna visas de som "provider not recorded". Välj den önskade Ollama- eller pluginposten på nytt för att låsa framtida förfrågningar till den.
• Personaposter behåller etiketten persona:<id>. För nya personaval registreras Ollama som bakomliggande leverantör. Historiska personasessioner utan leverantörsmetadata är fortsatt kompatibla med den äldre dirigeringen.

Work-problem

Work saknas eller rapporterar att körmiljön inte är tillgänglig

Work kräver ett konto som för närvarande är autentiserat och har åtkomst till Work: en administratör eller en aktiv användare när en administratör har öppnat Work för alla användare på fliken User Management i Settings. Dess containerkörmiljö måste vara tillgänglig för Libre WebUIs backend:

docker info
docker version

För Docker-backend som används som standard kontrollerar du att Docker körs och att den operativsystemsanvändare som kör Libre WebUI kan anropa det konfigurerade WORK_DOCKER_COMMAND. När Libre WebUI installeras med npx installeras inte Docker. Om körmiljön saknas håller Libre WebUI resten av applikationen tillgänglig och kör inte modellkommandon på värden som reservväg.

Repots Compose-filer aktiverar Work genom att montera värdens Docker-socket. I Kubernetes aktiverar du den inbyggda Pod/PVC-körmiljön med Helm-värdet work.enabled=true. Montera inte en körmiljösocket från en nod. När en Compose-driftsättning fortfarande rapporterar Runtime unavailable anger Work-sidan vilket av följande fall som gäller:

Meddelande	Orsak och åtgärd
The "docker" CLI is not installed…	En anpassad image saknar docker-cli. Använd den officiella imagen eller låt WORK_DOCKER_COMMAND peka på en CLI.
No Docker daemon is reachable…	Socketmonteringen har tagits bort eller värdens daemon har stoppats. Återställ monteringen i Compose-filen och starta Docker.
The Docker socket is mounted but…cannot open	Socketens grupp skiljer sig från containerns. Ange DOCKER_GID i .env (se nedan) och skapa om containern.
Works skärm/ljud stängs med WebSocket 1006 och loggar screen is unreachable	Den containerkörda backenden ringer upp sin egen loopback. På Docker Desktop använder du det medföljande WORK_DOCKER_PUBLISHED_HOST=host.docker.internal; på inbyggd Docker Engine anger du dessutom WORK_PREVIEW_BIND till Docker-bryggans icke-publika gateway och skapar sedan om Libre WebUI.

Läs socketgruppen via en container, eftersom en macOS-värd rapporterar ett annat värde än det som containern ser:

echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  alpine stat -c '%g' /var/run/docker.sock)" >> .env
docker compose up -d --force-recreate

Socketen ger kontroll motsvarande root över Docker-värden. Läs Work: Isolerade arbetsytor om vad det innebär för driftsättningen.

Modellen saknar verktygsstöd

Work kräver en chattmodell med verktygsstöd. För Ollama väljer du en installerad modell vars rapporterade förmågor omfattar tools. För en modell som stöds av ett plugin:

• Kontrollera att pluginet för chatt eller komplettering är aktivt.
• Kontrollera att den valda modellen finns i pluginets konfigurerade modellista.
• Kontrollera att en API-nyckel är tillgänglig för den aktuella administratören.
• Kontrollera att leverantören stöder verktygsanrop för just denna modell.

Libre WebUI dirigerar inte tyst om en misslyckad Work-körning till en annan leverantör.

En Work-begäran returnerar HTTP 429

Instansen har nått en antagningsgräns för uppgifter eller aktiva körmiljöer. Som standard tillåter Libre WebUI två aktiva containerbaserade uppgifter i hela instansen och en per användare. En pågående förhandsvisning tar också körmiljökapacitet i anspråk. Vänta tills den andra åtgärden är klar, stoppa en förhandsvisning som inte används eller be operatören granska inställningarna WORK_MAX_ACTIVE_RUNTIMES_* och WORK_MAX_TASKS_*.

Paketinstallation eller nätverksåtkomst misslyckas

Nya Work-uppgifter använder Dockers bryggnätverk så att genererade projekt kan hämta paket och starta förhandsvisningar. Kontrollera DNS för Docker, proxykonfigurationen, registrets tillgänglighet och kommandoutdata under Activity. Libre WebUI monterar inte värdens SSH-nycklar, molnautentiseringsuppgifter, webbläsarprofiler eller Docker-socket i uppgiftscontainern.

En Work-förhandsvisning startar inte

• Kontrollera att servern binder till 0.0.0.0 på WORK_PREVIEW_PORT (4173 som standard).
• Lämna det valfria kommandot tomt för att automatiskt identifiera ett dev-skript i package.json eller en vanlig index.html, även när det finns en enda nästlad app.
• Om Work rapporterar flera appar eller att en startpunkt som stöds saknas anger du projektets uttryckliga utvecklingskommando i det valfria kommandofältet. Kommandot startar i /workspace, så använd cd <app-directory> && ... för en nästlad app.
• Expandera felinformationen som returneras för att granska startutdata.
• Stoppa en befintlig förhandsvisning innan du startar ett annat kommando som behöver containern.

Förhandsvisningens URL:er använder en dynamiskt tilldelad loopback-port. Webbläsaren och Libre WebUIs backend måste därför köras på samma dator. En webbläsare som är ansluten till en fjärr-backend kan inte nå denna backends loopback-förhandsvisning, och en HTTPS-sida kan blockera en förhandsvisning via vanlig HTTP som blandat innehåll.

En arbetsytefil kan inte öppnas eller sparas

Works fil-API godtar UTF-8-textfiler på upp till 2 MB. Om en fil har ändrats sedan du öppnade den läser du in den på nytt innan du sparar, så att du inte skriver över den nyare versionen. Formatering är begränsad till filtyper som stöds och filer med färre än 100 000 tecken och 4 000 rader. Syntaxmarkeringen pausas för stora filer för att redigeringen ska förbli responsiv.

Ändringar som inte har sparats behålls som ett utkast i den aktuella webbläsaren. De ersätter inte en sparning i den beständiga arbetsytan.

En uppgift eller förhandsvisning stoppades

När du stoppar en körning eller förhandsvisning, eller startar om Libre WebUI, stoppas tillfälliga containerprocesser men uppgiftens namngivna arbetsytevolym bevaras. Öppna uppgiften igen och starta om förhandsvisningen. Att ta bort uppgiften fungerar annorlunda: efter bekräftelse tas uppgiften och dess arbetsyta bort permanent.

Inloggnings- och registreringsproblem

Den första användaren är inte administratör

Endast det första kontot som skapas i en ny databas blir administratör. Befintliga databaser behåller sina aktuella användare och roller.

JWT-fel

Ange en beständig hemlighet i produktionsmiljön:

JWT_SECRET=replace-with-a-long-random-secret

När JWT_SECRET ändras blir befintliga sessioner ogiltiga.

Turnstile blockerar registreringen

Turnstile aktiveras endast när båda nycklarna finns:

TURNSTILE_SITE_KEY=...
TURNSTILE_SECRET_KEY=...

Om registreringen plötsligt misslyckas kontrollerar du att webbplatsnyckeln motsvarar domänen och att den hemliga nyckeln är giltig.

OAuth-omdirigeringar misslyckas

Ange URL:er för återanrop både i leverantörens kontrollpanel och i .env för backend:

BASE_URL=https://your-domain.example
GITHUB_CALLBACK_URL=https://your-domain.example/api/auth/oauth/github/callback
HUGGINGFACE_CALLBACK_URL=https://your-domain.example/api/auth/oauth/huggingface/callback

Problem med dokumentchatt

Libre WebUI godtar PDF-, Office- (DOCX/PPTX/XLSX), Markdown-, HTML-, kod- och CSV-filer på upp till 10 MB.

Om sökningen fungerar men inte den semantiska hämtningen:

1. Installera en inbäddningsmodell, till exempel nomic-embed-text.
2. Aktivera inbäddningar i Settings.
3. Generera om inbäddningarna från dokumentinställningarna eller API:t.

ollama pull nomic-embed-text

Nyckelordssökningen fortsätter att fungera när inbäddningar är inaktiverade.

Problem med artefaktförhandsvisning

För spel eller interaktiv HTML ber du modellen skapa en enda fullständig, fristående HTML-fil med inbäddad CSS och JavaScript.

Om artefakten behöver tangentbordsinmatning:

• Klicka först i förhandsvisningen.
• Använd knappen Open för att köra den i en egen webbläsarflik.
• Undvik att förlita dig på lokala filer som inte ingick i svaret.

Libre WebUI kan paketera vanliga kodblock med index.html + CSS + JavaScript, men fristående HTML är fortfarande det mest tillförlitliga resultatet.

Docker-problem

Containern kan inte nå Ollama

Använd Compose-filen för extern Ollama när Ollama inte finns i samma Compose-stack:

docker compose -f docker-compose.external-ollama.yml up -d

Data bevaras inte

Montera en beständig datavolym och ange DATA_DIR vid behov. Krypteringsnyckeln lagras i den beständiga lagringen när DATA_DIR eller Docker-läge används.

Återställa lokala data

Stoppa appen först. Säkerhetskopiera och ta sedan bort den datakatalog som du använder. Som standard finns utvecklingsdata under backend/data.

cp -R backend/data backend/data.backup
rm -rf backend/data

Starta om backend och skapa ett nytt konto.

Fortfarande fast?

Öppna ett ärende och ange:

• Libre WebUI-version och commit
• installationsmetod
• operativsystem
• Node.js-version
• Ollama-version
• Docker-version och resultatet från docker info vid Work-problem
• backend-loggar från tiden kring felet
• fel i webbläsarkonsolen
• exakt vilken modell eller leverantör som används
• Work-utdata under Activity när en uppgift eller förhandsvisning misslyckas