No such export getSharedObject in resource es_extended: the fix

The full error usually looks like this, in the server console or in F8:

SCRIPT ERROR: @my_script/server/main.lua:1: No such export getSharedObject in resource es_extended

The code is right. exports['es_extended']:getSharedObject() is exactly how ESX Legacy hands out its object. The problem is when it runs: at that moment, es_extended is not there to answer.

#1. es_extended starts after your script

This is the cause nine times out of ten. FiveM starts resources in the order of your server.cfg, and a script that asks for ESX in its first line needs es_extended to be running already.

A safe order for an ESX server:

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

Watch out for folder categories like [scripts]: ensure [scripts] starts everything inside, so if that line comes before ensure es_extended, every script in it starts too early.

You can also make the script itself wait for ESX, by declaring the dependency in its fxmanifest.lua:

dependency 'es_extended'

FiveM will then start es_extended first, or refuse to start the script if it is missing.

#2. es_extended failed to start

If es_extended crashes while starting, its exports never exist. Scroll the server console up to the top and look for red lines from es_extended before your script's error. The usual culprits:

• The database. oxmysql cannot connect (a wrong password, a database that does not exist, MySQL not running). Check mysql_connection_string in your server.cfg:

set mysql_connection_string "mysql://user:password@localhost/es_extended?charset=utf8mb4"

• A missing dependency. Recent ESX Legacy builds need oxmysql and ox_lib started before them.
• Missing tables. A fresh install without the ESX SQL imported crashes on the first query.

Fix that first error and the export error disappears with it.

#3. The folder is not called es_extended

The export lives in a resource named exactly es_extended. These break it:

• the folder was renamed (es_extended-legacy, es_extended_main…);
• there are two copies of es_extended in different folders, and the wrong one starts;
• on a Linux host, the name has different capitals (ES_Extended): Linux is case-sensitive, Windows is not.

Search your resources folder for fxmanifest.lua files inside folders called es_extended and keep exactly one.

#4. You restarted es_extended while the server was running

restart es_extended from the console looks harmless, but every script that already took the ESX object keeps the old one, and anything that calls the export during the restart gets this error. After touching es_extended, restart the whole server, or at least restart the ESX scripts after it.

#5. The server is not ESX at all

If your server runs QBCore or QBox, there is no es_extended, and an ESX-only script fails exactly like this. Look in the script's config for a framework option, or use a version made for your framework. The QBCore equivalent of this error is covered in attempt to index a nil value (global 'QBCore').

#Checking it in ten seconds

In the server console:

ensure es_extended

If es_extended starts cleanly and the error persists, it is the start order. If it prints errors, fix those first. Then:

restart my_script

If the script now starts without the error, move its ensure below es_extended in server.cfg so it also works after a reboot.

#Summary