Skip to main content

​
Admin Menu File Permissions

The Admin Menu writes your configuration straight back to disk. On Linux that write can fail even though the panel looks like it worked — the config files stay untouched and your changes are gone after the next restart. Almost always the cause is ownership: the files belong to a different user than the one the FXServer process runs as.
This is rarely an issue on Windows, because the server usually runs under the same account that uploaded the files. On Linux those are two different users more often than not.

​
Which Files Need To Be Writable

The panel saves through FiveM’s SaveResourceFile, relative to the RoadPhone-Pro resource folder: The server process needs write permission on those files and on the directories containing them.

​
Diagnosing

1

Read the error

A failed save reports the reason in the panel and in the server console:
If you see this, continue below. If saving reports success but the values are back after a restart, you simply forgot to restart roadphone — see Admin Menu → Troubleshooting.
2

Find out which user runs FXServer

With txAdmin this is whoever started txAdmin. For a systemd service, check the unit:
3

Locate the resource folder

4

Confirm it really is a permission problem

Test as the server user instead of guessing — replace fivem and the path with your own values:
NOT_WRITABLE confirms it. WRITABLE means the permissions are fine and you should jump to Permissions Look Correct.

​
The Fix: Ownership

Give the resource folder to the user the server runs as. Substitute fivem and the path:
The classic cause: files uploaded over FTP/SFTP as root, while the server runs as fivem. 644 root:root leaves fivem with read-only access — exactly enough to start the resource, not enough to save from the panel.

​
Group write instead of ownership

If you would rather not transfer ownership, group write works too:
Do not reach for chmod -R 777. It fixes the symptom and makes the folder writable for every user on the machine — on a box hosting several servers or several customers that is a real risk. chown to the service user is just as quick and does not open that hole.

​
Docker and txAdmin Containers

Inside a container the permissions are often correct and the mount is read-only anyway. Check what the volume actually allows:
  • RW: false on the resources mount, or a :ro suffix on the resources volume in your docker-compose.yml, means no chmod will ever help — the :ro has to go.
  • The numeric UID has to match, not the user name. Compare docker exec <container> id against ls -n on the host.

​
Permissions Look Correct

If the write test passes and saving still fails:
SELinux can deny the write regardless of the file mode.
If saving works with SELinux permissive, set a proper file context for the folder rather than disabling SELinux permanently.
An i in the output means the file is immutable. Clear it with sudo chattr -i "$RES/config.lua".
An encrypted release build cannot be written to by SaveResourceFile at all. This fails on Windows the same way, so it only explains the problem if your Windows test server runs an unprotected build.
A ro mount option or a full disk both produce the same silent failure.

​
After Fixing

Configuration is read once at resource startup. Once saving succeeds, restart the resource to apply the values: