[BUG] Enhanced Build v90 to v97 - cfx_resource virtual filesystem cannot resolve nested resource files

[justciphertv]

Summary

FiveM Enhanced Build v90 to v97 appears to have an issue resolving nested files through the cfx_resource_ virtual filesystem.

Root-level files load correctly using LoadResourceFile(), but files inside nested directories fail. This breaks resources that depend on standard CitizenFX resource imports, such as ox_lib.

Example failing path:
cfx_resource_ox_lib:/imports/print/server.lua

Issue type

Server

Repro rate

Always

Server build version

3570

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

Linux (running in Docker/Pterodactyl container)

CPU

No response

RAM

No response

Using txAdmin?

Yes

Hosting provider

Self-hosted

Machine type

VPS

/perf endpoint output

Not relevant. Issue occurs during resource file resolution.

DDoS protection

No

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

Not using docker-compose. Running through Pterodactyl.

Steps to Reproduce

1. Install FiveM Enhanced server artifact build from v90 to 97.
2. Install the latest official ox_lib resource without modifications.
3. Start ox_lib.
4. Create a test resource that calls LoadResourceFile on a nested file inside ox_lib.
5. Observe that root files load successfully but nested files fail.

---

fxmanifest.lua

fx_version 'cerulean'
game 'gta5'

server_script 'server.lua'

server.lua

print("=== VFS TEST ===")

local root = LoadResourceFile("ox_lib", "init.lua")
print("root:", root ~= nil)

local nested = LoadResourceFile(
    "ox_lib",
    "imports/print/server.lua"
)

print("nested:", nested ~= nil)

Expected Behavior

LoadResourceFile() should successfully resolve nested files inside another resource.

Expected output:

root: true
nested: true

The following path should resolve:

cfx_resource_ox_lib:/imports/print/server.lua

Actual Behavior

Root-level resource files work.

Nested files fail.

Output:

root: true

[vfs-core] Attempted to open non-regular file:
/home/container/txData/Qbox_602A17.base/resources/[ox]/ox_lib/imports

[extra-natives-fi] Failed to open file
'cfx_resource_ox_lib:/imports/print/server.lua'
(original path imports/print/server.lua)
in resource 'ox_lib'

nested: false

Evidence

Logs:

[vfs-core] Attempted to open non-regular file:
/home/container/txData/Qbox_602A17.base/resources/[ox]/ox_lib/imports

[extra-natives-fi] Failed to open file
'cfx_resource_ox_lib:/imports/print/server.lua'

Working:

LoadResourceFile("ox_lib", "init.lua")

Fails:

LoadResourceFile("ox_lib", "imports/print/server.lua")

Affected resource:

ox_lib (official release, unmodified)

Additional Context

This issue appears to affect the newer resource import mechanism used by ox_lib.

ox_lib uses paths such as:

server_script '@ox_lib/imports/callback/server.lua'

These imports work on standard FXServer but fail on FiveM Enhanced Build v90 to v97.

The failure appears related to cfx_resource_ virtual filesystem path handling or nested resource file resolution.

The issue does not appear to be related to ox_lib itself because:

• ox_lib is unmodified
• root-level files resolve correctly
• qbx_core exports and other resource loading work correctly

A minimal reproduction is included above.

[wolfram-cfx]

Can you craft a small reproduction resource? I can not reproduce this on windows with a windows server.

[justciphertv]

I can provide a minimal reproduction resource. has been reproduce in both windows and Linux (Docker/Pterodactyl), LoadResourceFile("ox_lib", "init.lua") works as expected, but LoadResourceFile("ox_lib", "imports/print/server.lua") returns nil.

Server logs show:
Failed to open file 'cfx_resource_ox_lib:/imports/print/server.lua' and
Attempted to open non-regular file .../ox_lib/imports.

The same resource works correctly on a standard FXServer setup, so this appears specific to Enhanced Build v90–v97 both windows and linux.

resource repo: https://github.com/justciphertv/vfs_repro

[justciphertv]

you can see the error once you do a restart to the script it should print the true and false in server console for what working and what not

[Ikonizx]

Attached — vfs-logmiss, no dependencies, four files. ensure vfs-logmiss and read the console.

Two things are probably why it didn't reproduce:

1. The line is emitted on a MISS. If you probed nested files that exist, you'd correctly see nothing. The resource requests two paths that exist and two that don't, so the difference is visible in one boot.

2. I don't think this exists on master. I'm on FXServer-early-access b96 linux (gta5enhanced, sv_enforceGameBuild 3258). I string-searched master 32561 (Windows) and 33230 (Linux): cfx_resource, extra-natives, and non-regular file appear in neither, and extra-natives isn't in components.json on either platform. I validated the search against control strings (Stopping resource, svadhesive), which hit normally. Running this same resource on master 33230 gives correct results and zero log lines:

[1] paths that EXIST (expect no log lines):
exists.lua exists=true -> OK
nested/exists.lua exists=true -> OK
[2] paths that DO NOT exist (expect one log line each on affected builds):
missing.lua exists=false -> MISS
nested/missing.lua exists=false -> MISS

So a Windows master server is the negative control — it should look exactly like the above.

To be clear about scope: nested path resolution is fine. Results track file existence exactly and nesting depth is irrelevant. The ask is only that a LoadResourceFile miss not print at info, since nil is a documented outcome resources branch on — ox_lib probes ~20 paths per boot that way, and with a per-Lua-state cache every consuming resource re-probes. One ensure of 16 resources gave me ~155 lines.

[Section] [3] repeats one missing path 3× so you can see whether it dedupes.

(vfs-logmiss.zip)

[Ikonizx]

I'm having the same issue on Linux build 96.

Before you say "that's ox_lib's problem" — it isn't. Probing for optional files is normal, and the same calls are silent on master.

What you need to do:

LoadResourceFile misses are logged at info on Enhanced early-access (b96)

LoadResourceFile returning nil is a documented outcome that resources branch on. Early-access logs every miss to the console at info level:

[ info] [extra-natives-fi] Failed to open file 'cfx_resource_ox_lib:/imports/print/server.lua'
(original path imports/print/server.lua) in resource 'ox_lib'.

ox_lib resolves modules lazily — it probes imports/X/.lua and imports/X/shared.lua for every lib.X access and treats nil as "not present". 20 unique paths miss per boot, and the cache is per-Lua-state, so every consuming resource re-probes. One ensure of 16 resources produced ~155 lines. A full boot is worse. It makes the txAdmin console unusable.

This is not a VFS bug. Nested paths resolve fine — results track file existence exactly, nesting depth is irrelevant. imports/cron/server.lua and imports/logger/server.lua return true on b96 despite being nested and absent from ox_lib's files{}. Only nonexistent paths log.

It's a regression. Master 32561 and 33230 contain none of these strings and do the identical probing silently.

We can't work around it. Master has no gta5enhanced — only gta5 and rdr3 — so Enhanced requires early-access. No build without the logging, and no convar to disable it.

Ask: demote to debug/trace, or gate behind a convar (default off).

Minor: the line says in resource 'ox_lib' even while a different resource is starting, since LoadResourceFile targets ox_lib. Reads as ox_lib failing to load itself — that's what sent us down this path.
Env: FXServer-early-access b96 linux, gta5enhanced, sv_enforceGameBuild 3258, OneSync on, ox_lib 3.37.2.

[justciphertv]

The issue appears to be with FiveM Enhanced's Lua module resolution / virtual filesystem handling when resolving cross-resource require or import paths. Imports work when called internally within the same resource, but fail when another resource attempts to resolve modules from a dependency resource.

[Ikonizx]

Bump

[wolfram-cfx]

Is this still a thing with build 98?

[Ikonizx]

Yes, still present on b98 (hotfix 5). Confirmed two ways: my production server (FXServer-early-access b98 linux) and a clean local b98 pulled straight from the Enhanced Linux download URL.

Attached vfs-logmiss — 4 files, no dependencies, no ox_lib. ensure vfs-logmiss:

[1] paths that EXIST (expect no log lines):
exists.lua exists=true -> OK
nested/exists.lua exists=true -> OK
[2] paths that DO NOT exist:
[ info] [extra-natives-fi] Failed to open file 'cfx_resource_vfs-logmiss:/missing.lua' (original path missing.lua) in resource 'vfs-logmiss'. missing.lua exists=false -> MISS
[ info] [extra-natives-fi] Failed to open file 'cfx_resource_vfs-logmiss:/nested/missing.lua' (original path nested/missing.lua) in resource 'vfs-logmiss'.
nested/missing.lua exists=false -> MISS

Two corrections to how this was originally reported:

It's not nesting-related. missing.lua at the resource root logs identically to nested/missing.lua. Only existence matters, not depth. The nested-path framing in the original report was wrong.

It doesn't dedupe. Section [3] requests the same missing path 3× and gets 3 more lines. That's why volume scales — ox_lib probes ~20 paths per boot and its module cache is per-Lua-state, so every consuming resource re-probes. One ensure of 16 resources gave ~155 lines.

Re: Windows — I think you tested a master artifact. Master doesn't have this. There's a separate Enhanced Windows build (cfx-server_win_x64.zip, linked from the Enhanced download page); that's what should reproduce it.

To be explicit about scope: nothing is functionally broken. Paths resolve correctly, ox_lib loads, servers run. The ask is that a caller-initiated LoadResourceFile miss not print "Failed to open file" at info — nil is a documented return that resources branch on. Genuine mount/open failures should keep logging.

[justciphertv]

can confirm this is still a bug on build v98