No such export X in resource Y: how to fix it in FiveM

The console shows this, often in a loop:

SCRIPT ERROR: @my_script/server/main.lua:14: No such export GetItemCount in resource my_inventory

Your script called exports['my_inventory']:GetItemCount(). At that moment, my_inventory had no export with that name. The message names both parts, so the fix is one of a small number of causes. This guide covers the generic case. If the export is getSharedObject from es_extended, read No such export getSharedObject in resource es_extended instead, which has the ESX-specific causes.

#1. The resource is not started

An export only exists while its resource is running. Check the console at startup:

• Is the resource listed in server.cfg with ensure or start?
• Did it start without errors, or did it print Couldn't start resource or Failed to load script?
• Is it stopped in txAdmin? Check the Resources page.

A resource that failed to start, for example because of a Lua syntax error or a missing dependency, has no exports. Fix its own error first. See Couldn't start resource and could not find dependency. A syntax error in particular is covered in Lua syntax error: unexpected symbol near.

#2. The resource name is wrong

exports['my_inventory'] uses the folder name of the resource, not the title of the script. If the folder was renamed, every script that calls it by the old name fails.

Typical situations:

• You renamed my_inventory-master or my_inventory-main to something shorter and kept calling the old name.
• The name uses a hyphen in one place and an underscore in the other: my-inventory and my_inventory are different resources.
• The capitalisation differs: match the folder exactly.
• The resource sits in a folder with brackets such as [qb]. The brackets are only a category: they are not part of the name, so use my_inventory, not [qb]/my_inventory.

Some resources replace another with provide 'other_name' in their fxmanifest, so that scripts asking for the old name still work. If you replaced a resource with a compatible one and the old name fails, check whether the new one provides it, and that you removed the old folder so the two do not clash.

#3. The export is on the other side

Exports are per side. An export registered in a client script can only be called from another client script, and one registered on the server only from a server script.

-- my_inventory/server/main.lua
exports('GetItemCount', function(source, item)
    return 0
end)

-- my_script/client/main.lua
-- fails: GetItemCount exists on the server only
local count = exports['my_inventory']:GetItemCount('water')

To check, look in the provider's files: the exports(...) line is in client/ or server/, or in a file listed under shared_scripts, which runs on both sides. If the export is server-only, call it from a server script, and get the data to the client with an event or a callback, see server callbacks.

#4. The export was renamed or removed

Resources change between versions. An export called GetItemCount in an older release may be getItemCount or Search in a newer one, and Lua names are case sensitive. If the error appeared after an update of either resource:

1. Open the provider's fxmanifest.lua, README or documentation and look for the current export list.
2. Search the resource folder for exports( and for the name you call.
3. Update your call, or update the other resource to the version the script was written for.

Remember that the inverse also exists: a script updated to call a new export, while the provider still runs an old version without it.

grep -rn "exports(" resources/[mic]/my_inventory

On Windows, use the search box of your editor instead.

#5. Start order and dependencies

If the resource exists and has the export, but the call happens before it is ready, you get the same error. Resources start in the order of server.cfg:

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Put the provider above the script that uses it. For a permanent fix, state the link in the caller's fxmanifest.lua:

dependency 'my_inventory'

Then FiveM starts my_inventory first, and refuses to start the script without it. More on ordering in server.cfg resource order.

Two related traps:

• The export is registered late. exports('Name', fn) runs when the line is reached. If the file errors above it, or registers it after a long Wait, callers that run in the meantime fail. Register exports near the top of the file.
• A call at load time. A top-level call such as local count = exports['my_inventory']:GetItemCount('water') runs the moment your file loads. Move it into an event or a thread, or make sure the dependency is already running.

You can also protect an optional integration with pcall and with a check that the resource is running:

if GetResourceState('my_inventory') == 'started' then
    local ok, count = pcall(function()
        return exports['my_inventory']:GetItemCount('water')
    end)
end

GetResourceState returns 'started', 'stopped', 'missing' or other states, so you can also log which case it is. For a deeper look at how exports work, read FiveM exports in Lua.

#6. Restarted one resource, not the other

Restarting a provider while the server runs does not always re-connect the scripts that hold its objects. After you restart or update a provider, restart the scripts that call it, or restart the server.

#Checklist