Recover Satisfactory administrator access without deleting the world

Recover a forgotten administrator password by resetting the dedicated server's identity settings, then reclaiming that server and loading the existing session. The important boundary is the single server settings file, separate from the factory saves. Deleting every .sav file would remove the data you are trying to preserve.

This guide is for the owner of a PC dedicated server with host, service, and file access. If you only have the player password, ask the owner to perform recovery. If an administrator can still authenticate, change the password through Server Manager instead of resetting the server's identity.

Plan for more than a password change#

The documented settings-file reset also resets the server name, player password, automatic session selection, and the default game-generated certificate state. Write down the intended name, session, access restrictions, and relevant settings before maintenance. Do not expect the previous session to load automatically after reclaiming.

Arrange a maintenance window and limit access to the administrator's trusted network path before restarting an unclaimed server. Keep that restriction until you have reclaimed it and restored player protection. Only the trusted owner should be able to reach the unclaimed instance.

With the default game-generated certificate, the fingerprint can change after this operation. A separately installed custom certificate and private key are outside this settings file; preserve that deployment and verify which identity the restarted server actually presents. Clients should verify the served identity through a trusted administrator. See the certificate verification guide. Do not teach players to dismiss every future certificate warning.

Identify the settings file belonging to this instance#

The filename is ServerSettings.PORT.sav, where PORT is the server's configured game port. For example, the default-port instance uses ServerSettings.7777.sav. Do not choose a file by an old guide's port number, and do not change the server's port merely to make a filename match.

For a directly launched process, typical locations are:

Here ~ and %LOCALAPPDATA% belong to the account running the server. A Windows service can use a service profile; a container can map this data elsewhere. Trace the active process account and persistent mount before editing. An administrator's own profile may contain an unrelated client installation.

The settings file sits above the server world-save directory. Confirm both the selected identity file and the actual factory files. Several similarly named settings files can belong to different instances or earlier ports; do not reset them all. If the expected file is absent, investigate the account, port, and mount instead of creating a guessed directory.

Stop, back up, and move only that file aside#

Ask players to finish and preserve a completed checkpoint if existing access allows it. Stop this instance using its service or container manager. Confirm the process has stopped and that an automatic restart policy has not immediately started it again. Check whether the deployment normally updates on startup; a password recovery should not unexpectedly become a version migration.

With the server stopped, back up its persistent save data, blueprints, configuration, and the selected settings file to a protected location outside the active directories. Retain file ownership and the current build/mod information. The settings data includes identity and credential-related fields, so do not attach this backup to a public support ticket.

Move the one matching ServerSettings.PORT.sav into that backup location, recording its original path. This makes it absent from the active location, as required by the documented reset, while retaining a reversible copy. Leave world .sav files, blueprint directories, and other instances untouched. Do not open the binary settings file in a text editor to replace a password string.

Reclaim and select the existing factory#

Start the same instance with its original data mapping and intended build. In Server Manager, select its verified address and reclaim the unclaimed server. Set a new administrator password and store it in a password manager. Restore the server name and player password before allowing normal access.

Open Manage Saves, select the intended existing session and completed checkpoint, and load it. Set or verify the automatic session selection and review the remaining server options. Do not create a new game to repair an empty save list: first inspect the persistent files, account, and mount.

Join from a compatible client and check recognizable factory areas, inventories, and recent progress. Complete a save, then perform a controlled restart and confirm the same session returns and administrator authentication works. Reclaiming alone does not verify the factory or future startup behavior.

Stop if recovery touches the wrong state#

If the server remains claimed, stop and recheck the active instance, port, and file location. Repeatedly removing more files is not a useful diagnosis. If the intended factory is missing, preserve the current state and compare it with the backup before replacing anything.

To undo an accidental settings reset, stop the instance and restore the original settings file with its ownership, retaining the newly generated one separately. This restores the old identity state, including the old password problem; it is a rollback, not password recovery. Keep the independent world backup until the intended server has passed the save-and-restart checks.

For ongoing administration of your own infrastructure, Nexardo's product overview describes a central management approach. Keep recovery access and protected backups documented alongside the specific instance.

Sources#

• Satisfactory Wiki: administrator reset and instance file locations

• Satisfactory Wiki: server settings data

• Pterodactyl maintainer documentation: reset the settings file while retaining world saves

• Community container documentation: persistent data and process accounts

• Historical discussion: forgotten dedicated-server administrator password

• Optional custom-certificate deployment: separate certificate and key files