FiveM resource-fejl: Couldn't load resource og alle de andre

Couldn't find og Couldn't load, manglende dependencies, manifest-fejl, escrow, Awaiting scripts og streaming-advarsler - hvad hver fejl betyder, og hvem der kan se den.


Læs den her forskel først - den løser halvdelen af sagerne

To fejl ligner hinanden og bliver forvekslet konstant. De kommer fra hver sin maskine og har intet med hinanden at gøre:

Fejl Hvor den opstår Hvad den betyder
Couldn't find resource <navn> Serveren Serveren kender slet ikke den resource
Couldn't load resource <navn> Spillerens klient Filen blev hentet, men kunne ikke pakkes ud

Find er dit problem: mappen hedder noget andet, ligger forkert, eller er ikke blevet scannet endnu.

Load er et overførselsproblem hos spilleren - typisk en ødelagt cache. Det er sjældent noget, du har gjort.

Farvekoder i loggen: kører du serveren gennem et script eller piper loggen til en fil, ser du sekvenser som ^1, ^3 og ^7 midt i teksten. Det er farvekoder, ikke en del af fejlen. De forsvinder i den almindelige konsol.


Couldn't find resource <navn>

Serveren fandt ikke en resource med det navn.

Årsager:

  1. Mappenavnet passer ikke med det navn, du skriver i ensure. Navne er versalfølsomme på Linux
  2. Resourcen blev lagt ind, efter serveren sidst scannede - kør refresh
  3. Mappen har ingen gyldig fxmanifest.lua, så scanningen sprang den helt over
  4. Mappen ligger i en kategori i firkantede parenteser, som ikke bliver startet

Beslægtede beskeder fra samme sted: Couldn't find resource category <navn>, Couldn't start resource <navn> og Couldn't stop resource <navn>.


Couldn't load resource sessionmanager

Den fulde fejl hos spilleren ser typisk sådan ud:

Couldn't load resource sessionmanager: Failed to open packfile:
ReadBulk of header failed: Failed to fetch: Failed to add entry to
local storage (download corrupted?)

Andre haler du vil se: Invalid magic, HTTP 403: filter failed : not a valid client, eller Unknown error.

Navnet i fejlen er som regel ikke synderen. sessionmanager og spawnmanager er systemresources, og de er blandt de første, klienten henter. Er der noget galt med selve overførslen, rammer det derfor næsten altid dem - uanset hvilken resource der reelt er noget galt med.

Melder flere spillere forskellige resource-navne, er det et overførselsproblem, ikke et resource-problem.

Årsager, i rækkefølge:

  1. Ødelagt cache hos spilleren. Klart hyppigst, og det er ikke din skyld. Bed dem slette deres FiveM-cachemappe
  2. En proxy eller CDN foran serveren, der roder med filoverførslerne. Halen HTTP 403: filter failed : not a valid client er kendetegnet - typisk Cloudflare der filtrerer klientens filhentninger. Slå filtrering fra på filoverførslerne, eller fjern proxyen
  3. Reelt ødelagte filer på serveren efter en dårlig FTP-upload. Giver Invalid magic
  4. En meget stor resource, der timer ud midt i overførslen

Could not find dependency <x> for resource <y>

For eksempel Could not find dependency es_extended for resource esx.

Hvad det betyder: resourcens manifest siger, at den kræver en anden resource, og den anden resource er ikke kendt af serveren.

Årsager:

  1. Afhængigheden er slet ikke installeret. Bemærk at async og mysql-async er to forskellige ting - det er en klassisk forveksling i ESX
  2. Afhængigheden ligger på disken, men er ikke scannet. Kør refresh
  3. Mappenavnet passer ikke. En mappe ved navn es_extended-master opfylder ikke dependency 'es_extended'. Omdøb den
  4. Afhængigheden har selv en ødelagt eller manglende fxmanifest.lua og blev derfor sprunget over i scanningen - den ligger på disken, men er usynlig
  5. Rækkefølgen i server.cfg - afhængigheden skal startes først

Manifest-fejl

Under opstart scanner serveren resources-mappen og skriver én linje per problem. De præcise beskeder:

<navn> does not have a resource manifest (fxmanifest.lua)
<navn> has an outdated manifest (__resource.lua instead of fxmanifest.lua)
<navn> exists in more than one place (<sti> is used, the duplicate is <sti>)
<navn> is a category, but has a resource manifest
Resource <navn> does not specify an fx_version in fxmanifest.lua.
Resource <navn> does not support the current game (<spil>).

Tre ting værd at vide:

Manglende manifest er kun en advarsel. Mappen springes over, og serveren starter fint. En ødelagt manifest er derimod en fejl.

Advarselsfarvet, men alligevel fatalt: beskederne om fx_version og manglende spilunderstøttelse skrives som advarsler, men resourcen bliver afvist. Folk skimmer forbi dem og forstår så ikke, hvorfor resourcen aldrig starter.

exists in more than one place er den mest oversete. Har du to kopier af samme resource, bruger serveren den ene - og du sidder og redigerer den anden. Det er forklaringen på "jeg har rettet filen, og der sker ingenting".

Er der syntaksfejl i selve manifestet, får du i stedet:

Could not parse resource metadata file <sti>: <lua-fejl>
Could not execute resource metadata file <sti>: <lua-fejl>

Parse betyder syntaksfejl i manifestet. Execute betyder, at manifestet er syntaktisk korrekt, men fejlede da det blev kørt.

Filer nævnt i manifestet, som ikke findes

could not find client_script client/main.lua (defined in fxmanifest.lua:12)

Præcis besked med linjenummer og det hele. Den er guld værd og bliver stort set aldrig nævnt andre steder.


Script-fejl

Der er tre linjer, og de kommer altid sammen:

Error parsing script @minresource/server/main.lua in resource minresource: <lua-fejl>
Failed to load script server/main.lua.

Failed to load script alene siger næsten ingenting. Den er altid foregået af en Error parsing- eller Error loading-linje, som indeholder den egentlige fejl. Folk kopierer typisk kun den sidste linje.

Parse = syntaksfejl i filen. Loading = filen kørte og fejlede - ofte fordi en afhængighed ikke var klar endnu, altså reelt et rækkefølgeproblem.

Fejl under drift ser sådan ud:

SCRIPT ERROR: @minresource/client/main.lua:42: attempt to index a nil value (global 'ESX')

@ foran stien er ikke en fejl. Det er en Lua-konvention, og den er nyttig: det, der står mellem @ og den første skråstreg, er altid navnet på resourcen. Det er sådan du finder synderen ud fra et skærmbillede fra en spiller.


Failed to verify protected resource <navn>

Gælder betalte scripts med escrow-beskyttelse.

Årsager, i rækkefølge:

  1. .fxap-filen blev ikke uploadet. Mange FTP-programmer springer den over, fordi de læser den som en skjult fil. Tjek at den ligger i resourcens rodmappe
  2. Delvis eller ødelagt upload. Upload hellere den originale .zip og pak den ud på serveren end at uploade løse filer
  3. FTP i ASCII-tilstand ødelagde filen. Brug binær overførsel
  4. Serveren blev ikke genstartet efter installationen

En beslægtet fejl er You lack the required entitlement to use <navn>. Den betyder noget helt andet: filerne er fine, men serverens licensnøgle tilhører en anden Cfx-konto end den, der købte scriptet. Opret en nøgle fra den rigtige konto.

En misvisende fejl du skal kende: en Lua-syntaksfejl med et uforståeligt tegn omkring linje 1 i en escrow-beskyttet fil ser ud som en fejl i koden, men betyder i virkeligheden, at den krypterede fil blev læst som almindelig tekst - altså det samme som årsag 1 og 3. Folk bruger timer på at "rette" Lua, der ikke fejler.


Fast på "Awaiting scripts"

Det er ikke en fejl - det er en tilstand. Klienten har alle filer og venter på, at serverens scripts giver grønt lys. Den timer aldrig ud, så der kommer ingen fejltekst.

Årsager:

  1. spawnmanager eller sessionmanager kører ikke, eller er crashet
  2. En framework-resource fejlede under sin egen opstart og nåede aldrig at melde klar
  3. Et script fejlede inde i spawn-håndteringen - synligt i spillerens F8-konsol
  4. En ødelagt loading screen, der aldrig lukker sig selv

Kig i serverkonsollen, ikke hos klienten. Den egentlige fejl står som regel i serverens opstart, flere minutter tidligere. Sørg for at ensure spawnmanager og ensure sessionmanager står i din server.cfg - mangler de, forklarer det alene problemet.


Connection rejected by server: Resource prevented connection.

Hvad det betyder: en resource afviste spilleren - ikke serveren selv. Typisk et kø-, whitelist-, ban- eller anticheat-script.

Står der en anden tekst efter kolonet, er det den besked, resourcen selv gav. Står der præcis Resource prevented connection., gav den ingen besked - ofte fordi den fejlede undervejs i sin egen kontrol.

En beslægtet: Failed handshake to server <adresse> - it closed the connection while deferring betyder, at serveren døde eller lukkede forbindelsen midt i tilslutningen.


Streaming-advarsler

Asset minemods/vehicle.ytd uses 34.2 MiB of physical memory.

Over 48 MiB tilføjes desuden:

Oversized assets can and WILL lead to streaming issues
(such as models not loading/rendering).

Grænserne er:

Størrelse Hvad der sker
Over 16 MiB Advarsel
Over 32 MiB Advarsel, gul
Over 48 MiB Advarsel med den skarpe formulering ovenfor
Over 64 MiB Advarsel, rød

Der er ingen hård grænse på 16 MB. Det påstås overalt, men 16 MiB er blot den første advarselstærskel. Filer over den størrelse indlæses stadig - de bliver bare mere og mere problematiske.

Hos spilleren viser det sig som Failed to call inflate() for streaming file <navn>.ytd eller Streaming data in archive is corrupt - som regel en ødelagt upload.


Game build og versioner

This server requires a different game build (<x>) from the one you're using (<y>).
Client/Server game build revision mismatch: you are running game build <x>
revision <y>, while server expects revision <z>.

Sættes med sv_enforceGameBuild i server.cfg. Den er startup-only og kan ikke ændres, mens serveren kører.

Et lidt overset tilfælde: en resource kan selv kræve en bestemt game build i sit manifest. Så får du sv_enforceGameBuild needs to be at least <x> (current is <y>) - og "resourcen vil ikke starte" er i virkeligheden et versionsproblem.


Hvor ligger loggen - og hvordan får du fejlen ud af spilleren?

FXServer skriver ingen logfil af sig selv. Konsollen er loggen. Kører du txAdmin - og det gør du, hvis du fulgte txAdmin og resources - ligger de gemte logs under txData/<profil>/logs/.

Det vigtigste at forstå: en fejl i et client_script er usynlig for dig. Serveren får den aldrig at se. Det er derfor, du kan stå med en tom konsol, mens spilleren har en rød fejl på skærmen.

Sådan får du den ud af spilleren:

  1. Bed dem trykke F8 for at åbne klientkonsollen
  2. Bed om et skærmbillede scrollet helt til toppen - den første fejl er årsagen, resten er følgefejl
  3. Spørg til det præcise tidspunkt, så du kan finde det tilsvarende sted i serverkonsollen
Fejl Hvem ser den
Manifest, dependency, Couldn't find resource Kun serveren
Fejl i server_script Kun serveren
Fejl i client_script Kun spilleren (F8)
Couldn't load resource Kun spilleren
Streaming-advarsler ved opstart Serveren
Connection rejected by server Spilleren, men årsagen er på serveren

ensure, start, restart og refresh

Kommando Hvad den gør
start <navn> Starter, hvis den er stoppet. Gør intet hvis den kører
restart <navn> Genstarter, kun hvis den allerede kører
ensure <navn> Virker i begge tilfælde. Brug den her
stop <navn> Stopper resourcen
refresh Genscanner mappen og opdager nye resources

Tre fælder:

  • restart på en stoppet resource gør ingenting
  • refresh er nødvendig efter du har lagt nye filer ind - ellers får du Couldn't find resource
  • refresh genstarter ikke det, der allerede kører. Har du rettet et manifest, skal du køre refresh og restart

Gode råd

  • Læs loggen oppefra og ned. Den første fejl under opstart er næsten altid årsagen til alle de følgende.
  • Tilføj resources én ad gangen og genstart imellem.
  • Upload betalte scripts som den originale .zip og pak ud på serveren. Det fjerner hele escrow-kategorien af fejl.
  • Hold din server.cfg i rækkefølge: database, framework-kerne, og derefter alt det, der bruger dem.
  • Melder flere spillere forskellige resource-navne i samme fejl, så led efter noget i overførslen - ikke i resourcerne.

Kan du ikke placere en fejl? Send os de første 30 linjer af serverkonsollen fra opstart, og et F8-skærmbillede fra en ramt spiller.

FiveMBestil nu

Guide information

Udgivet
6. september 2026
Sidst opdateret
8. september 2026
Visninger
26