Ox Doorlock FiveM: setup, permissions and door testing

Dependencies and framework scope

The published installation documentation lists oxmysql and ox_lib as required dependencies, with ox_target optional for additional functionality. It describes standalone use and integrations including ox_core, qbx_core and es_extended. Verify the bridge and versions in the exact package you install; a Qbox integration is not blanket proof that every QBCore fork works unchanged.

Record the resource revision, dependency versions and framework before configuring doors. The repository source reviewed for this guide was revision 553e85d. Keep that record alongside your staging configuration so a future update can be compared with a known environment.

Use a built release or build the source UI

Use a packaged release or build the source web UI in ox_doorlock/web, following the installation guide. For a cursor without an interface, check the UI build before editing door settings.

Capture resource startup and client-console errors. Confirm the installed folder contains the expected release files and that its dependencies start successfully. Preserve a copy of your configuration before replacing the package. Avoid stacking several copies of the same door manager while trying to identify which one owns a doorway.

Check /doorlock editor permission separately from player access

The documented server-console diagnostic is test_ace player.1 command.doorlock, replacing 1 with the relevant server player ID. It tests the command permission; it does not grant it. Follow your server’s administration policy when assigning editor access.

A staff member opening the configuration UI does not establish that an ordinary player has the intended access to a door. Plan two separate tests: who may edit entries, and who may lock or unlock each configured entrance. Keep permission changes scoped to the intended role rather than granting everyone administration access to make a test pass.

Create one entry and select the intended door entities

The reviewed repository describes opening /doorlock, entering settings, confirming them and using the targeting interaction to select the relevant entity or entities. For a paired entrance, inspect both leaves and verify that the saved entry controls the intended pair. Check the actual input binding in your installed environment instead of assuming every player uses the same key.

Give the entry a name that identifies its location and purpose. Keep a note of the resource and map package responsible for that entrance. A useful first test is one known doorway on a staging server, followed by a second client observing the result. Magnate has not performed this workflow inside GTA V.

Understand access rules and movement settings

The settings reference distinguishes a default locked state, an autolock interval and Hold Open, which holds a door open while unlocked. Double controls a paired set; Automatic is for sliding, garage or automatic doors. These options describe different behaviors, so an unlocked entrance is not necessarily meant to remain physically open.

Access-related fields include framework character identifiers, groups with minimum grades and item conditions. The documented passcode can let anybody who knows the code or phrase unlock the door. Review the intended access design before adding a passcode to a job-restricted entrance; do not assume one field merely decorates another restriction.

Use the existing MLO doors-not-closing guide when the issue is movement. Use this setup guide for the installation and authorization path. A portal definition in an interior asset is a separate map concept and does not itself implement a player-access policy.

Test authorized and unauthorized users before rollout

Use this proposed acceptance checklist with your installed resource and map. Record observed results rather than marking a row complete because the UI saved successfully. Repeat the important checks after reconnecting and after a controlled resource restart on staging.

Treat old-door conversion as a separate migration

The repository describes converting nui_doorlock configuration files from the convert directory into database entries, while warning that forks such as the qb variant may not convert successfully. Back up the existing data and rehearse conversion on a separate staging copy. An import completing is not evidence that every entity and access rule survived correctly.

Compare entry counts, door identities and authorization behavior before and after conversion. Keep the prior system available for rollback, but avoid having both managers actively control the same door during normal operation. This guide does not execute a migration or claim compatibility with every historic configuration format.

Questions, answered.