Gaming4Free — Free Game Server Hosting G4F.GG v1.0 // FREE FOREVER
BACK TO BLOG
HOME / BLOG / Server Guides
Server Guides

File Manager Checklist: Fix What Matters (Skip the Rest)

If you run a game server long enough, you eventually end up in the file manager at 2am. Not because you planned to. But because something broke. Or a plugin won’t load. Or your server is stuck in a boot loop and the console is just… screaming.

And yeah, file managers are empowering. Also dangerous. One wrong delete, one “I’ll just rename this real quick”, and suddenly you’re restoring backups and pretending you meant to spend your night that way.

So this is a practical checklist for what you should change in your server file manager, what you should leave alone, and how to avoid the classic mistakes. It’s written for people hosting things like Minecraft, Terraria, FiveM, and similar servers, especially if you’re using a panel based host like Gaming4Free (G4F) where you get direct access to your files but you still want the server to, you know, actually start.

Before you touch anything, do this first

This part is boring. It’s also the part that saves you.

1. Make a backup you can actually restore

Not “I think the host has backups”. Not “I’ll remember what I changed”.

Do one of these:

  • Download a copy of the important folders to your PC.
  • Use the host’s backup feature if it exists.
  • Duplicate the file or folder inside the file manager (if the panel supports it), like server.properties.bak or plugins_backup/.

Minimum viable backup for most servers:

  • Minecraft: world/, world_nether/, world_the_end/, plugins/, config/ (if present)
  • FiveM: resources/, server.cfg, database credentials file (if you use one), any custom scripts
  • Terraria: your world files and player files (depends on setup, but the world is the big one)

If you’re hosting on Gaming4Free.net, treat it the same way you’d treat any serious host. Free doesn’t mean careless. Make the backup anyway.

2. Write down what you’re changing (seriously, just a tiny note)

A simple text file called changes.txt in the root is fine.

Example:

  • “Changed server.properties: online-mode true to false”
  • “Updated LuckPerms config”
  • “Added resource pack link”

When something breaks later, this note becomes your future self’s alibi.

3. Stop the server before editing core configs

Some files can be edited live, some absolutely shouldn’t. In general:

  • Stop the server before changing configs, permissions, world settings, resource lists.
  • You can often edit small text files while running, but it’s still a risk and changes may not apply until restart anyway.

If you’re not sure, stop it. Your uptime can survive a 30 second restart.


The “Safe to Change” checklist (most of the time)

These are the files that usually exist to be edited. Like, that’s the point.

1. Server config files (the obvious ones)

These vary by game, but the usual suspects:

Minecraft

  • server.properties
  • bukkit.yml, spigot.yml, paper-global.yml, paper-world-defaults.yml (depends on your server software)
  • Anything in plugins/<PluginName>/config.yml

FiveM

  • server.cfg
  • Resource config files inside resources/

Terraria

  • Config files your host setup provides (some setups auto generate these)
  • World path settings if you’re changing world files

These are meant to be changed. The danger is not editing them. The danger is editing them carelessly.

Quick tips that prevent dumb issues:

  • Watch for quotes and spacing.
  • Don’t paste random config blocks from 2017 forum posts without checking version compatibility.
  • Keep a copy of the original before you “improve” it.

2. Whitelists, admin lists, permissions, ban lists

These are almost always safe and common.

Minecraft examples

  • whitelist.json
  • ops.json
  • banned-players.json
  • banned-ips.json
  • Permission plugin files (LuckPerms, PermissionsEx, etc)

Still, avoid hand editing JSON unless you know what you’re doing. JSON breaks easily. One missing bracket and the server refuses to load it. If the game or plugin has commands for it, use the commands.

But if you must edit:

  • Validate JSON with a validator tool.
  • Keep formatting consistent.
  • Don’t leave trailing commas.

3. Plugin configs and data (with a little caution)

Changing plugin configs is normal. That’s how you customize a server.

What’s usually safe:

  • config.yml files
  • Messages files (language files)
  • Feature toggles, permissions, chat formats, economy settings

What needs more care:

  • Plugin databases or storage files
  • Anything in a plugin folder called data/, storage/, db/, userdata/

If a plugin says “do not edit while server is running”, believe it. If it says “don’t touch this file”, also believe it. Plugin authors write those warnings because people like us ignore them.

4. Resource packs, server icons, MOTD text

These are fun changes. Low risk.

Minecraft

  • server-icon.png (must be 64x64)
  • MOTD in server.properties
  • Resource pack URL and hash in server.properties

Worst case, you mess up the icon or the MOTD looks weird. It won’t delete your world.

5. World folders, but only in specific ways

This is where people get brave. Sometimes it works. Sometimes it’s a disaster.

Safe-ish changes:

  • Uploading a new world folder (like moving from a template world to your own)
  • Renaming a world folder if you also update the config that points to it
  • Downloading your world for backups

Risky changes:

  • Deleting region files to “fix lag” without knowing what you’re deleting
  • Merging worlds by dragging folders into each other
  • Editing world files while the server is running

If you’re swapping a world, the clean method is:

  1. Stop server
  2. Backup existing world folder
  3. Upload new world folder with correct name
  4. Confirm config points to it
  5. Start server
  6. Join and verify spawn, inventories, plugin data

Also, some plugins store location data tied to the world name. Renaming world to world2 can break warps, claims, protection regions, and more. Not always. But often enough.

6. Logs (viewing, downloading)

Reading logs is safe. Deleting logs can be safe too, but only if you know why.

If your disk space is tight, old logs can pile up. You can usually delete ancient ones. Just don’t delete logs you still need to debug an issue that is happening right now. That’s… a mood.


The “Change Carefully” checklist (you can do it, just slow down)

These are the areas where one small change can have a bigger impact than you think.

1. Anything involving ports, IP binding, networking

Some server configs let you set:

  • Server port
  • Bind IP / endpoint
  • Proxy settings (Velocity, BungeeCord, etc)
  • Query ports

Changing these can make your server appear “offline” even when it’s running.

If you’re on a hosting platform, often the port is assigned and should not be changed manually unless the host explicitly tells you to. So if you changed a port and now nobody can join, yeah.

Undo that first.

2. Java flags, startup arguments, and launch configs

This is one of the biggest “I watched a YouTube optimization video” traps.

People paste startup flags designed for a dedicated machine with a specific CPU, and then wonder why the server crashes on launch.

If you’re using a panel host:

  • There may be a startup tab for flags. Prefer that over editing random launch scripts.
  • Don’t crank memory beyond what you’re actually allocated.
  • Don’t add flags you don’t understand.

Performance tuning is real. But random tuning is just gambling.

3. Permission systems and ranks

Permissions are a slow burn problem. You change a few things, it seems okay, then three days later someone can suddenly run /stop.

If you’re editing rank files:

  • Keep a “default” group that is locked down.
  • Grant admin perms deliberately, not by pasting “all permissions” lists.
  • Test with a normal user account, not your op account.

And yeah, it’s annoying. But so is someone giving themselves creative and deleting your spawn.

4. Databases and credentials (FiveM especially)

If you run scripts that use MySQL or external services, you’ll have credential files or config blocks.

Do not:

  • Post them in screenshots
  • Paste them into Discord help channels
  • Leave old credentials lying around in backups you share

If you’re rotating credentials, change them in one place at a time, test, then move to the next. Half updated credentials cause the worst “it kind of runs but nothing saves” bugs.


The “Do NOT Change Unless You Know Exactly Why” checklist

These are the ones that get people. The files that look harmless, but are basically load bearing walls.

1. Core binaries and server jars (without a plan)

Examples:

  • server.jar, paper.jar, spigot.jar
  • FiveM base server binaries
  • Anything that looks like the engine itself

Updating is fine. Replacing is fine. But do it intentionally:

  • Confirm compatibility (plugins, mods, scripts)
  • Keep the old jar as a rollback option
  • Read the update notes if it’s a major version jump

Randomly swapping jars because “this one is faster” is how you end up with a dead server and a confused friend group asking why the world is gone.

2. The libraries/ folder, runtime folders, dependency folders

Most platforms generate these. They can be rebuilt, but if you delete the wrong thing you can cause:

  • startup failures
  • missing class errors
  • endless re download loops

Unless a guide specifically instructs you to clear a cache folder to fix a specific bug, leave these alone.

3. Player data folders (unless you are fixing a specific player issue)

Minecraft examples:

  • world/playerdata/
  • world/advancements/
  • world/stats/

These files control inventories, ender chests, achievements, and more. Deleting them can “fix” a stuck player, sure.

It also can wipe their inventory and make them quit your server forever. So.

If one player is bugged, move their file somewhere safe instead of deleting it:

  • Stop server
  • Move UUID.dat to playerdata_backup/
  • Start server
  • Let them rejoin, confirm the fix
  • Decide what you want to restore later

4. Anything labeled as “generated” by the system

If the host created it, or the panel warns you about it, don’t fight it.

Examples:

  • Auto generated config folders
  • Panel metadata files
  • Container settings files

If you’re on Gaming4Free or any similar platform, there are files that exist to help the panel manage your server. Deleting or editing those can cause weird behavior that feels supernatural. Like, “why did my server type change” weird. Leave it.

5. Modloader internals (Forge, Fabric, etc)

If you run modded Minecraft:

  • Don’t delete random files in mods/ without checking dependencies.
  • Don’t edit .jar mods.
  • Don’t remove “core” mods without knowing what they do.

If you suspect a mod is breaking startup, use a clean isolation method:

  1. Stop server
  2. Move half the mods out
  3. Start server
  4. Narrow down the culprit

Not glamorous, but it works.


The “Most Common File Manager Mistakes” (so you can avoid them)

Mistake 1: Editing configs with the wrong format

YAML is famous for this. One wrong indentation and everything breaks.

If you edit YAML (config.yml):

  • Use spaces, not tabs
  • Keep indentation consistent
  • If a plugin provides a default config, compare yours to it

Mistake 2: Renaming folders without updating references

Rename world to myworld and forget to update the setting? Server generates a fresh world called world again. Now you think the world “reset”.

It didn’t reset. You just booted the wrong folder.

Mistake 3: Uploading files while the server is running

Sometimes you get away with it. Sometimes you corrupt something.

Stop the server for:

  • worlds
  • databases
  • big plugin data files
  • resource packs if you’re updating hashes
  • anything that players interact with live

Mistake 4: Deleting to “clean up” without understanding the file

If you don’t know what it is, don’t delete it yet. Move it to a quarantine folder:

Create: __old/ or quarantine/

Then move suspicious files there, restart, test. If everything works for a day or two, then delete.

This one habit saves so many servers.


A simple decision rule (use this when you’re unsure)

Ask:

  1. Is this file clearly meant to be user edited? (config, whitelist, messages)
  2. Can I restore it easily if I mess up? (backup exists, default file available)
  3. Will changing it affect player data or world integrity? (if yes, slow down)
  4. Do I know what “success” looks like after I change it? (test plan)

If you can’t answer those, pause. Go read the docs. Or test on a spare server instance first.

If you don’t have a spare instance and you’re experimenting, honestly, this is where a free host is nice. You can spin up a test server on something like Gaming4Free (gaming4free.net) and try changes there before you touch your “real” world. It’s not fancy. It’s just… sensible.


Quick checklist summary (copy this into a note)

Change freely (usually)

  • server.properties / server.cfg and normal config files
  • plugin configs in plugins/<name>/
  • whitelists, ops, ban lists (prefer commands, but files are ok)
  • MOTD, icons, resource pack links
  • view/download logs

Change carefully

  • ports, bind settings, proxy settings
  • startup flags, memory settings, launch parameters
  • permissions and rank structures
  • database credentials and script configs
  • world swaps and renames

Don’t touch unless you’re sure

  • server binaries and jars without a rollback plan
  • libraries/ and dependency folders
  • playerdata folders (unless fixing a specific player)
  • host panel generated files
  • modloader internals and random “required” mods

Closing thought (because this stuff matters more than people admit)

A file manager is basically power tools. You can build a great server with it. You can also cut through something important without realizing until later.

If you’re doing server hosting the practical way, especially on a platform like Gaming4Free where you can get started without monthly payments, the smartest thing you can do is build good habits early. Backups. Small changes. One test at a time. Keep notes. It’s not overkill. It’s just how you keep a server alive longer than a weekend.

And if you want a low pressure place to experiment, spin up a test server on https://gaming4free.net and break things there first. It’s oddly freeing, messing up on purpose where it doesn’t hurt.

FAQs (Frequently Asked Questions)

What should I do before editing any files in my game server's file manager?

Before touching anything, always make a backup you can actually restore. This can be downloading important folders to your PC, using your host's backup feature, or duplicating files/folders within the file manager. Also, write down any changes you make in a simple text file like 'changes.txt' to keep track. Lastly, stop the server before editing core configuration files to avoid issues.

Which server files are generally safe to change and commonly edited?

Files meant to be edited include server config files such as 'server.properties' for Minecraft, 'server.cfg' for FiveM, and relevant config files in Terraria setups. Whitelists, admin lists, permissions, ban lists (e.g., 'whitelist.json', 'ops.json'), and plugin config files like 'config.yml' are also usually safe. Just be cautious with JSON formatting and plugin data files.

How can I safely edit JSON files like whitelists or permissions without breaking my server?

Avoid hand-editing JSON unless you're confident. Use commands provided by the game or plugins when possible. If you must edit manually, validate your JSON with an online validator tool, maintain consistent formatting, avoid trailing commas, and keep backups of original files to prevent loading errors.

Are there any specific precautions when changing plugin configuration or data files?

Yes. Editing plugin config files like 'config.yml' is typically safe for customization. However, avoid editing plugin databases or storage folders (like 'data/', 'storage/', 'db/', or 'userdata/') especially while the server is running. Always heed plugin warnings about editing restrictions to prevent corrupting data or causing crashes.

Is it risky to modify world folders directly in the file manager?

Modifying world folders can be risky if not done carefully. Safe actions include uploading a new world folder, renaming a world folder if you update related configs accordingly, and downloading worlds for backups. Risky actions include deleting region files without understanding their purpose or attempting to merge worlds improperly.

What are some low-risk customizations I can make to enhance my Minecraft server's appearance?

You can safely change resource packs by updating URLs and hashes in 'server.properties', customize the server icon by replacing 'server-icon.png' with a 64x64 image, and edit the Message of the Day (MOTD) text in 'server.properties'. These changes are fun and low risk—they won't affect your worlds or core functionality.

Frequently Asked Questions

What should I do before editing any files in my game server's file manager?

Before touching anything, always make a backup you can actually restore. This can be downloading important folders to your PC, using your host's backup feature, or duplicating files/folders within the file manager. Also, write down any changes you make in a simple text file like 'changes.txt' to keep track. Lastly, stop the server before editing core configuration files to avoid issues.

Which server files are generally safe to change and commonly edited?

Files meant to be edited include server config files such as 'server.properties' for Minecraft, 'server.cfg' for FiveM, and relevant config files in Terraria setups. Whitelists, admin lists, permissions, ban lists (e.g., 'whitelist.json', 'ops.json'), and plugin config files like 'config.yml' are also usually safe. Just be cautious with JSON formatting and plugin data files.

How can I safely edit JSON files like whitelists or permissions without breaking my server?

Avoid hand-editing JSON unless you're confident. Use commands provided by the game or plugins when possible. If you must edit manually, validate your JSON with an online validator tool, maintain consistent formatting, avoid trailing commas, and keep backups of original files to prevent loading errors.

Are there any specific precautions when changing plugin configuration or data files?

Yes. Editing plugin config files like 'config.yml' is typically safe for customization. However, avoid editing plugin databases or storage folders (like 'data/', 'storage/', 'db/', or 'userdata/') especially while the server is running. Always heed plugin warnings about editing restrictions to prevent corrupting data or causing crashes.

Is it risky to modify world folders directly in the file manager?

Modifying world folders can be risky if not done carefully. Safe actions include uploading a new world folder, renaming a world folder if you update related configs accordingly, and downloading worlds for backups. Risky actions include deleting region files without understanding their purpose or attempting to merge worlds improperly.

What are some low-risk customizations I can make to enhance my Minecraft server's appearance?

You can safely change resource packs by updating URLs and hashes in 'server.properties', customize the server icon by replacing 'server-icon.png' with a 64x64 image, and edit the Message of the Day (MOTD) text in 'server.properties'. These changes are fun and low risk—they won't affect your worlds or core functionality.

READY TO START HOSTING?

Deploy your free game server in under 60 seconds. No credit card, no trial — free forever.

DEPLOY FREE SERVER →