starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 06:05:57 +03:00

[GH-ISSUE #4644] [Bug]: satisfactory 1.0 unable to launch #2885

New issue

Closed

opened 2026-02-27 03:06:04 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 03:06:04 +03:00

Owner

Originally created by @ewlidd on GitHub (Sep 10, 2024).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4644

User story

as a server admin, I want the server exe to launch and have the correct ports

Game

satisfactory

Linux distro

Debian 12

Command

command: start

Further information

satisfactory 1.0 just launched.
I applied the following fixes to make it run, most of which I guess will be fixed by satisfactory themselves in time, so this is more or less a doc for those that want a manual fix in the meantime.
TL;DR:
-there's a new port TCP 7777, that incorrectly binds to localhost if you use the -multihome flag effectively locking you out from the server.
-They also changed the server executable name that needs new symlinks.

#remove symlink
rm /home/satisfactory/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping  
#replace symlink to new exe  
ln -s /home/satisfactory/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/satisfactory/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping
#create another new symlink to new exe
ln -s /home/satisfactory/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/satisfactory/serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping

Satisfactory has a new port requirement of TCP 7777. This will give an error when browsing to the server of "failed to connect to the server api"
you must edit your config and remove -multihome ${ip} from the launch flags.
for some reason, when the satisfactory launches with the multihome flag it binds to 127.0.0.1:7777 instead of the multihome IP (or 0.0.0.0).

Relevant log output

No response

Steps to reproduce

No response

Originally created by @ewlidd on GitHub (Sep 10, 2024). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4644 ### User story as a server admin, I want the server exe to launch and have the correct ports ### Game satisfactory ### Linux distro Debian 12 ### Command command: start ### Further information satisfactory 1.0 just launched. I applied the following fixes to make it run, most of which I guess will be fixed by satisfactory themselves in time, so this is more or less a doc for those that want a manual fix in the meantime. TL;DR: -there's a new port TCP 7777, that incorrectly binds to localhost if you use the -multihome flag effectively locking you out from the server. -They also changed the server executable name that needs new symlinks. ``` #remove symlink rm /home/satisfactory/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping #replace symlink to new exe ln -s /home/satisfactory/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/satisfactory/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping #create another new symlink to new exe ln -s /home/satisfactory/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/satisfactory/serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping ``` Satisfactory has a new port requirement of TCP 7777. This will give an error when browsing to the server of "failed to connect to the server api" you must edit your config and remove -multihome ${ip} from the launch flags. for some reason, when the satisfactory launches with the multihome flag it binds to 127.0.0.1:7777 instead of the multihome IP (or 0.0.0.0). ### Relevant log output _No response_ ### Steps to reproduce _No response_

kerem

2026-02-27 03:06:04 +03:00

closed this issue
added the
type: bug

distro: Debian

command: start

game: Satisfactory
labels

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@ehcorn commented on GitHub (Sep 10, 2024):

also can't launch after the new update, get the error: "serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping" however replacing the symlinks didn't work for me, still says executable not found. Oddly my files are in the sfserver user home directory not in a satisfactory sub-directory so I have a different folder structure to ewildd. I've got a fresh ubuntu 20.04 install that's only setup to run the LGS script.

edit: Nevermind, I went directly to the folder and fixed launch by replacing the symlinks, launches now. Havent had a chance to test the port issue.

@ehcorn commented on GitHub (Sep 10, 2024): also can't launch after the new update, get the error: "serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping" however replacing the symlinks didn't work for me, still says executable not found. Oddly my files are in the sfserver user home directory not in a satisfactory sub-directory so I have a different folder structure to ewildd. I've got a fresh ubuntu 20.04 install that's only setup to run the LGS script. edit: Nevermind, I went directly to the folder and fixed launch by replacing the symlinks, launches now. Havent had a chance to test the port issue.

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@timvandenhof commented on GitHub (Sep 10, 2024):

Same issue here, had to replace satisfactory with the default sfserver to make the symlinks work:

#remove symlink
rm /home/sfserver/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping  
#replace symlink to new exe  
ln -s /home/sfserver/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/sfserver/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping
#create another new symlink to new exe
ln -s /home/sfserver/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/sfserver/serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping

Also had to remove the multihome from the config. After that it seems to work fine, at least on the local network.

@timvandenhof commented on GitHub (Sep 10, 2024): Same issue here, had to replace `satisfactory` with the default `sfserver` to make the symlinks work: ``` #remove symlink rm /home/sfserver/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping #replace symlink to new exe ln -s /home/sfserver/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/sfserver/serverfiles/Engine/Binaries/Linux/UE4Server-Linux-Shipping #create another new symlink to new exe ln -s /home/sfserver/serverfiles/Engine/Binaries/Linux/FactoryServer-Linux-Shipping /home/sfserver/serverfiles/Engine/Binaries/Linux/UnrealServer-Linux-Shipping ``` Also had to remove the multihome from the config. After that it seems to work fine, at least on the local network.

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@svanegmond commented on GitHub (Sep 10, 2024):

Edit lgsm/config-default/config-lgsm/sfserver/_default.cfg. Change startparameter to read startparameters="FactoryGame -port=${port} -log". Jump ahead to line 160 or so, and change the executable to read: executable="./FactoryServer-Linux-Shipping".

The lgsm check_executable.sh needs to have the hack for SF update 7 removed from it, the first 'if' clause.

Further, if your server starts and still cannot connect, there is a bug in the game where if ipv6 is not enabled in your server it will listen to 127.0.0.1:7777 only. Verify this with lsof -ni | grep 7777. The solution is to enable ipv6 in your kernel, then you should see it bound to *:7777. If you can't figure out getting ipv6 enabled in the kernel, use rinetd to forward connections.

@svanegmond commented on GitHub (Sep 10, 2024): Edit `lgsm/config-default/config-lgsm/sfserver/_default.cfg`. Change `startparameter` to read `startparameters="FactoryGame -port=${port} -log"`. Jump ahead to line 160 or so, and change the `executable` to read: `executable="./FactoryServer-Linux-Shipping"`. The lgsm check_executable.sh needs to have the hack for SF update 7 removed from it, the first 'if' clause. Further, if your server starts and still cannot connect, there is a bug in the game where if ipv6 is not enabled in your server it will listen to 127.0.0.1:7777 only. Verify this with `lsof -ni | grep 7777`. The solution is to enable ipv6 in your kernel, then you should see it bound to *:7777. If you can't figure out getting ipv6 enabled in the kernel, use rinetd to forward connections.

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@FlickyFlack commented on GitHub (Sep 10, 2024):

Edit lgsm/config-default/config-lgsm/sfserver/_default.cfg. Change startparameter to read startparameters="FactoryGame -port=${port} -log". Jump ahead to line 160 or so, and change the executable to read: executable="./FactoryServer-Linux-Shipping".

The lgsm check_executable.sh needs to have the hack for SF update 7 removed from it, the first 'if' clause.

Further, if your server starts and still cannot connect, there is a bug in the game where if ipv6 is not enabled in your server it will listen to 127.0.0.1:7777 only. Verify this with lsof -ni | grep 7777. The solution is to enable ipv6 in your kernel, then you should see it bound to *:7777. If you can't figure out getting ipv6 enabled in the kernel, use rinetd to forward connections.

Can confirm this to be working. I've used a clean slate and deleted everything Satisfactory related and did a fresh install using ./sfserver install
Created the new Symlinks as explained by @timvandenhof (the clean installation does not need to remove the old symlink)
Also changed the start parameters as explained by you.
Interestingly, my IPv6 Port did not get mapped and I was still able to join (although it is enabled in the kernel)

root@<FunnyName>:~# lsof -ni | grep 7777
FactorySe 2404317        sfserver   13u  IPv4 46335836      0t0  TCP *:7777 (LISTEN)
FactorySe 2404317        sfserver   15u  IPv4 46335858      0t0  UDP *:7777

@FlickyFlack commented on GitHub (Sep 10, 2024): > Edit `lgsm/config-default/config-lgsm/sfserver/_default.cfg`. Change `startparameter` to read `startparameters="FactoryGame -port=${port} -log"`. Jump ahead to line 160 or so, and change the `executable` to read: `executable="./FactoryServer-Linux-Shipping"`. > > The lgsm check_executable.sh needs to have the hack for SF update 7 removed from it, the first 'if' clause. > > Further, if your server starts and still cannot connect, there is a bug in the game where if ipv6 is not enabled in your server it will listen to 127.0.0.1:7777 only. Verify this with `lsof -ni | grep 7777`. The solution is to enable ipv6 in your kernel, then you should see it bound to *:7777. If you can't figure out getting ipv6 enabled in the kernel, use rinetd to forward connections. Can confirm this to be working. I've used a clean slate and deleted everything Satisfactory related and did a fresh install using `./sfserver install` Created the new Symlinks as explained by @timvandenhof (the clean installation does not need to remove the old symlink) Also changed the start parameters as explained by you. Interestingly, my IPv6 Port did not get mapped and I was still able to join (although it is enabled in the kernel) ``` root@<FunnyName>:~# lsof -ni | grep 7777 FactorySe 2404317 sfserver 13u IPv4 46335836 0t0 TCP *:7777 (LISTEN) FactorySe 2404317 sfserver 15u IPv4 46335858 0t0 UDP *:7777 ``` ![image](https://github.com/user-attachments/assets/0cce0692-94d3-46f0-b5b2-a58da656902c) ![image](https://github.com/user-attachments/assets/f78c3963-fca6-494d-8739-3ca72be45a81)

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Sep 10, 2024):

Hotfix now released

@dgibbs64 commented on GitHub (Sep 10, 2024): Hotfix now released

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@svanegmond commented on GitHub (Sep 11, 2024):

Yeah, sorry to be unclear, ipv6 needs to be present in OS to provide a ::1 to bind to, even if you don't use it at all.

@svanegmond commented on GitHub (Sep 11, 2024): Yeah, sorry to be unclear, ipv6 needs to be present in OS to provide a ::1 to bind to, even if you don't use it at all.

kerem commented

2026-02-27 03:06:05 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 15, 2025):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Sep 15, 2025): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:55:57 +03:00

[PR #2894] [MERGED] feat(avorion): remove avgalaxy variable and replace with selfname #3827