@ox_lib/init.lua not found and ox_lib errors: how to fix

A script that uses ox_lib fails to load in your console and the message mentions @ox_lib/init.lua, or it fails with:

No such export <name> in resource ox_lib

or ox_lib itself never starts. All of these come from the same few causes: the wrong download, the wrong folder name, the wrong start order, or a missing line in the manifest. Here is the fix for each.

#What ox_lib is

ox_lib is a shared library that many scripts rely on: callbacks, notifications, menus, progress bars, locales. A script opts in with one line in its manifest:

shared_script '@ox_lib/init.lua'

The @ox_lib/ prefix tells FiveM to read the file from the resource called ox_lib, not from the script's own folder. So ox_lib must exist, have exactly that name, and be started.

#1. Download the release, not the source zip

This is the cause most people hit. On GitHub, the green Code button gives you a zip of the source. ox_lib has a web interface (menus, progress bars) that is built from source files. The source zip does not contain the built files, so ox_lib either fails to load its UI or logs a message about the UI not being built.

Instead:

1. Open the ox_lib repository on GitHub, then Releases.
2. On the latest release, download the file named ox_lib.zip under Assets.
3. Unzip it. The folder inside must be ox_lib and fxmanifest.lua must sit directly in it.

resources/[standalone]/ox_lib/fxmanifest.lua

If you have a source folder called ox_lib-main, remove it and install the release instead. See also Could not find dependency for folder name problems.

#2. Start ox_lib before the scripts

In server.cfg, ox_lib must come before any resource that imports it:

ensure oxmysql
ensure ox_lib
ensure es_extended   # or qb-core / qbx_core

ensure my_script

If my_script is ensured above ox_lib, it may load first and fail. Moving it down is the fix. See the right ensure order in server.cfg.

Add the dependency in the script's manifest as well, so FiveM checks it:

dependency 'ox_lib'

#3. Add the shared script and lua54

Scripts that use lib. functions need two lines in fxmanifest.lua. Without the import, lib is nil in the script, and you get errors like attempt to index a nil value (global 'lib'):

fx_version 'cerulean'
game 'gta5'

lua54 'yes'

shared_script '@ox_lib/init.lua'

client_scripts { 'client/*.lua' }
server_scripts { 'server/*.lua' }

The order matters: shared_script '@ox_lib/init.lua' must be listed so it loads before the script files that call lib. Put it above client_scripts and server_scripts.

#4. No such export in resource ox_lib

No such export <name> in resource ox_lib

This means the script calls an ox_lib export that does not exist on your server. There are two causes:

• An old ox_lib. The script was written for a newer release. Update to the latest release build.
• ox_lib failed to start, so none of its exports exist. Look at the console where ox_lib starts. If it printed an error there, fix that first.

Check that ox_lib starts cleanly: run ensure ox_lib in the server console and read what prints. A healthy start prints no error and no failure line.

#5. Check the server artifact

ox_lib needs a reasonably current FiveM server build. If ox_lib refuses to start and the message mentions the server version, update your artifacts. The steps are in updating FiveM server artifacts.

#6. The script itself is not at fault

If ox_lib is installed and started, but one script still breaks, confirm that:

• The script's own folder is named as its ensure line says.
• You did not copy ox_lib into the script's folder. There must be one ox_lib resource, at the top level of resources (or in a bracket folder).
• No second copy of ox_lib exists in another category folder. Two folders with the same resource name cause unpredictable behaviour.

Tip: when you update ox_lib, delete the old folder first instead of unzipping over it. Old files left behind can mix with new ones.

#Checklist