You add three new scripts to a server that was running fine an hour ago. You restart, and players are falling through the floor, a job menu refuses to open, or the whole thing will not start at all. That moment feels chaotic, but it is not random.

Short answer: Resource conflicts follow predictable patterns, a broken manifest, a load order problem, a duplicate collision file, or a script built for the wrong framework. Read your server logs top-down and stop at the first failure, confirm the culprit with txAdmin and Resmon, fix manifest issues before touching code, check framework compatibility explicitly, and address map conflicts with the right tools. Work through them in order and you will find the problem.

Reading your server logs before you touch a single file

Most operators try to fix conflicts by disabling random scripts and restarting over and over. That approach wastes hours. The right starting point is always the server console output, which tells you exactly which resource broke and why, if you know what to look for.

The most common error messages and what they actually mean

  • "No such export in resource": a script is calling a function from another resource that has not loaded yet. This is a load order problem, not a broken script.
  • "Attempt to index a nil value": the script is reaching for a variable that does not exist, usually because a dependency failed to initialize before this resource started.
  • "Resource does not exist": your server.cfg has an ensure line for a resource the server cannot find on disk. Double-nested folders are the most common cause.
  • "Couldn't load resource: failed to open packfile": the resource files are corrupted or incomplete, often after a partial download.
  • "You lack the required entitlement": the escrow system cannot verify ownership of a premium asset, and every script that depends on it will fail downstream.
  • Duplicate resource names: two scripts share the same folder name or export the same function, and FiveM cannot resolve the conflict.

FiveM errors cascade. The first error in the log is almost always the actual problem, and every line that follows is a symptom of it. When operators scroll down to find the most dramatic crash message, they are reading the consequence rather than the cause. Read top-down and stop at the first failure. Fix that one issue, restart, and let the log tell you what is left.

For startup failures, check the txAdmin live console first, it shows resource start errors in real time as the server initializes. For mid-session crashes, pull the server output log file on disk, because the live console may have already scrolled past the relevant lines. Client-side errors visible in the F8 console are useful for diagnosing what a specific player experiences, but they are the wrong place to start when diagnosing a server-side resource conflict.

Using txAdmin and Resmon to isolate the exact culprit

Once you know what the error says, you need to confirm which resource is causing it. txAdmin and the built-in resource monitor give you that confirmation without guesswork.

Open your txAdmin panel and go to the Monitoring section. The resource list shows which resources started cleanly and which logged errors on initialization. Cross-reference crash timestamps with resource activity to rule out false positives. Enable txAdmin's auto-restart policy while diagnosing so the server stays online and you can keep testing without manual intervention after each restart.

Running resmon and reading the Time% column

Type resmon into the server console to open the Resource Monitor. The Time% column shows what percentage of CPU time each resource is consuming per tick. A resource that spikes to an abnormally high Time% right before a crash is almost always the source of the problem.

Manifest and dependency errors

The fxmanifest.lua file is the first thing FiveM reads when it loads a resource. If it is wrong, missing, or structured incorrectly, the resource will not start, and every script that depends on it will fail in a chain reaction.

Manifest syntax and what to check first

Every manifest requires two things at minimum: fx_version 'cerulean' and game 'gta5'. Beyond that, adding a lua54 'yes' declaration is strongly recommended for modern Lua 5.4 support; it is not strictly required to load, but omitting it on current server builds will cause compatibility issues with most 2026 scripts. The most common mistake right now is operators still using __resource.lua patterns or mixing legacy table syntax with the current format. If your resource includes any NUI assets like HTML, CSS, or JavaScript, those file paths must be declared in a files block or they simply will not load, producing errors that look completely unrelated to the manifest. If you are unsure about current manifest syntax, the official FiveM documentation covers the current format and common pitfalls.

Double-nesting and folder structure errors

The double-folder problem is one of the most frequent causes of "Resource does not exist" errors. It happens when a downloaded ZIP extracts into a subfolder, so the manifest ends up at resources/my-resource/my-resource/fxmanifest.lua instead of resources/my-resource/fxmanifest.lua. You can spot it instantly by checking whether the folder name inside the resource directory matches the folder name you are trying to ensure.

Fixing dependency chains and load order within the manifest

The dependencies entries in your manifest must exactly match the folder name on disk, including capitalization. On Linux servers, Config.lua and config.lua are two different files, and the wrong case will break your resource on deployment even if it worked fine on Windows locally. Reorder your shared_script entries so libraries initialize before the scripts that call them. If a library's init file is not loaded first, every function it defines will be nil when the dependent script tries to call those functions.

Framework-specific conflict patterns in ESX, QBCore, and Qbox

Framework conflicts are a different category from manifest errors. They happen when scripts built for one system get installed on another, or when two resources inside the same framework compete over the same exports, events, or database tables.

Why ESX and QBCore scripts are never interchangeable

There is zero native compatibility between them. ESX uses different exports, events, and database schema than QBCore, and running both frameworks simultaneously is not possible. Any resource must explicitly state its framework compatibility, and that declaration must match your server's stack exactly. If a script description does not clearly specify which framework it supports, that is a warning sign before you even download it. If you hit persistent "No such export" errors while migrating frameworks, the Cfx.re forum has extensive threads on this exact error.

Identifying Qbox-specific conflicts with OX inventory

Qbox ships with OX inventory and ox_lib by default. As of August 2024, OX Inventory officially dropped support for QBCore, which means QBCore scripts that reference qb-inventory will conflict or fail silently on a Qbox server. Before installing any resource on a Qbox server, open its fxmanifest.lua and config files. Look for hardcoded references to qb-inventory or QBCore.Functions. Those references need to be updated to the OX equivalents, or you need a version of the script that explicitly supports Qbox.

Verifying framework compatibility before you install anything

The pre-install check takes two minutes and saves hours of debugging. Open fxmanifest.lua, check the dependencies array, and confirm every listed dependency exists on your server and matches your framework version. Scripts that claim to support "all frameworks" deserve the same scrutiny because they often ship with legacy code paths that have not been tested against current framework versions.

Fixing MLO collisions and map asset conflicts

MLO conflicts are the most disorienting to diagnose because the symptoms are visual: players fall through floors, lights float in mid-air, or buildings render with missing geometry. The cause is almost always duplicate collision files or unmerged Y maps between two resource packs.

Diagnosing falling-through-map and floating prop issues

The two root causes are missing or broken YBN collision geometry and duplicate .ybn, .ydr, or .ymap files across multiple MLO resources. To identify which MLO is responsible, disable your map resources one at a time and test after each restart. The conflict becomes obvious when the visual problem disappears after removing a specific resource.

Using CodeWalker to merge Y maps and repair YBN data

Always enable DLC support before opening any files in CodeWalker; skipping this step means custom MLO assets will not load correctly. Load the MLO folder, then switch to Collision view to look for gaps in geometry where players are falling through. Use the Entities view to locate and delete duplicate or floating props. After making changes, save multiple times until the star icon next to the modified file disappears, then restart your server and test the affected area before considering the fix complete.

Two categories of tooling cut diagnosis time significantly on servers with large map packs: automated duplicate-file scanners that check resource folders for repeated names across MLOs, and manual isolation by disabling one map resource at a time. On servers running many map resources, running an automated scan before manually disabling resources one by one will spare you a significant stretch of methodical testing.

Prevention habits that keep conflicts from coming back

Fixing an existing conflict is reactive. The operators who run stable servers follow a short set of habits that stop conflicts from forming in the first place.

The load order template every server.cfg needs

The correct sequence is: database wrappers first, then the core framework, then base systems, then job scripts, then vehicles and weapons, then miscellaneous utilities, then maps and MLOs last. This order is not arbitrary. The framework needs database access available on startup, and each subsequent tier depends on the one above it being fully loaded before any of its exports are callable. Putting a job script before the framework or a map resource before the base systems will produce errors that look like script bugs but are actually load order violations. For a practical load-order template you can copy into your server.cfg, see our server.cfg performance checklist.

A pre-install checklist for every new resource

Before adding any script, run through these checks: confirm the manifest has valid syntax and all required fields, verify the dependency list matches your server's actual installed resources, and test the resource in isolation on a staging copy before pushing to production. Skipping the staging step is how one broken resource takes down an entire live server during peak hours. For a structured pre-purchase and pre-install workflow, see our Server X-Ray audit guide.

The teams who run conflict-free servers document their stack, their load order, and their install process. Memory fails, especially when you are adding your fortieth resource six months after initial setup.

When the problem runs deeper than the logs

Most conflicts bottom out at one of the layers covered here. Start with the logs, confirm with txAdmin and Resmon, fix manifest issues before touching code, check framework compatibility explicitly, and address map conflicts with the right tools. Work through them in order and you will find the problem.

For deeper stack issues, version mismatches between frameworks, cascading failures across many resources, or conflicts that disappear and reappear unpredictably, a second set of experienced eyes saves days of debugging. A script compatibility audit before launch, or a full Server X-Ray if you are already live, gives you a clear diagnosis and action plan instead of more guesswork. For broader reading on why servers stop unexpectedly, see our guide on reviving a dying FiveM server.