Operation not permitted [/opt/factorio/bin/x64/../../config/config.ini]

[pmoisel]

After a while my friend and me wanted to come back to factorio.
So i updated my server to 1.1.107 (stable) and got this:

0.000 Error Util.cpp:86: filesystem error: cannot make canonical path: Operation not permitted [/opt/factorio/bin/x64/../../config/config.ini]

I checked older versions and the server will run a container up to 1.1.100, updating to 1.1.101 or newer results in error stated above.

Any suggestions?

[fank]

Can you share how you start the container?
So I may be able to reproduce it.

[pmoisel]

Sure. I have a systemd-service:

[Unit]
Description=Factorio Server
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker stop factorio4
ExecStartPre=-/usr/bin/docker rm factorio4
ExecStartPre=/usr/bin/docker pull factoriotools/factorio:stable
ExecStart=docker run \
        -d \
        -p 34200:34197/udp \
        -v /home/factorio4:/factorio \
        --name factorio4 \
        -e LOAD_LATEST_SAVE=false \
        -e SAVE_NAME=archievement.zip \
        factoriotools/factorio:stable
ExecStop=/usr/bin/docker stop factorio4
User=factorio
Group=factorio
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

resulting in:

docker logs factorio4 -f   
+ FACTORIO_VOL=/factorio
+ LOAD_LATEST_SAVE=false
+ GENERATE_NEW_SAVE=false
+ PRESET=
+ SAVE_NAME=archievement.zip
+ BIND=
+ CONSOLE_LOG_LOCATION=
+ mkdir -p /factorio
+ mkdir -p /factorio/saves
+ mkdir -p /factorio/config
+ mkdir -p /factorio/mods
+ mkdir -p /factorio/scenarios
+ mkdir -p /factorio/script-output
+ [[ ! -f /factorio/config/rconpw ]]
+ [[ ! -f /factorio/config/server-settings.json ]]
+ [[ ! -f /factorio/config/map-gen-settings.json ]]
+ [[ ! -f /factorio/config/map-settings.json ]]
++ find -L /factorio/saves -iname '*.tmp.zip' -mindepth 1
++ wc -l
+ NRTMPSAVES=0
+ [[ 0 -gt 0 ]]
+ [[ '' == \t\r\u\e ]]
+ EXEC=
++ id -u
+ [[ 0 = 0 ]]
+ usermod -o -u 845 factorio
usermod: no changes
+ groupmod -o -g 845 factorio
+ chown -R factorio:factorio /factorio
+ EXEC='runuser -u factorio -g factorio --'
+ [[ -f /bin/box64 ]]
+ sed -i '/write-data=/c\write-data=\/factorio/' /opt/factorio/config/config.ini
++ find -L /factorio/saves -iname '*.zip' -mindepth 1
++ wc -l
+ NRSAVES=1
+ [[ false != true ]]
+ [[ 1 == 0 ]]
+ [[ false == true ]]
+ FLAGS=(--port "$PORT" --server-settings "$CONFIG/server-settings.json" --server-banlist "$CONFIG/server-banlist.json" --rcon-port "$RCON_PORT" --server-whitelist "$CONFIG/server-whitelist.json" --use-server-whitelist --server-adminlist "$CONFIG/server-adminlist.json" --rcon-password "$(cat "$CONFIG/rconpw")" --server-id /factorio/config/server-id.json)
++ cat /factorio/config/rconpw
+ '[' -n '' ']'
+ '[' -n '' ']'
+ [[ false == true ]]
+ FLAGS+=(--start-server "$SAVE_NAME")
+ exec runuser -u factorio -g factorio -- /opt/factorio/bin/x64/factorio --port 34197 --server-settings /factorio/config/server-settings.json --server-banlist /factorio/config/server-banlist.json --rcon-port 27015 --server-whitelist /factorio/config/server-whitelist.json --use-server-whitelist --server-adminlist /factorio/config/server-adminlist.json --rcon-password SOMESECRETPW --server-id /factorio/config/server-id.json --start-server archievement.zip
   0.000 Error Util.cpp:86: filesystem error: cannot make canonical path: Operation not permitted [/opt/factorio/bin/x64/../../config/config.ini]

[pmoisel]

any update?

[Adversarius13293]

We had pretty much the same problem. Up to version 1.1.101 everything was fine. But every version tested from 102 to 110 had the same error message. Even when setting up a new container without any save game.
We tried many different things, but nothing worked. So our last option was a new host os, since we were still using Ubuntu 19. Now with Ubuntu 22 everything is working for us.

[pierluc-codes]

I got the same problem so I brushed my docker skills to understand what was happening.

The problem is this PR added a user to the dockerfile. In particular this line where the ownership of /opt is changed. This does not play well with the user you also created on your system because it most probably have a different gid and uid.

IMO it is a mistake to deal with the user in the DOCKERFILE. That being said, the quickest way to fix your poblem is to change the uid/gid on your system to the one expected by the DOCKERFILE.

usermod -u 845 factorio # this change the userid
groupmod -g 845 factorio # this change the groupid

and fix the owernship of the factorio folder.

something along the line of:

chown -R 845:845 /home/factorio4 # or whatever path your using with -v

It fixed my problem, I hope it will fix yours also!

[Adversarius13293]

But that PR you linked is from 2020. Why would that make problems when switching to version 1.1.100 (or 101)?
Also the Quick Start guide already mentions that they use

a 'factorio' user with user id 845

and that you have to permit that user. Which I double checked to do.

The file or path mentioned in the error message /opt/factorio/bin/x64/../../config/config.ini is not part of the host system, so that shouldn't even be relevant on my first glance?

Your statement might not be wrong, but I don't think it is related to this problem. Even though I can't test ist anymore myself, since we reinstalled our host server.

[pierluc-codes]

Also the Quick Start guide already mentions that they use

You are right. Reading the quick start guide it is not super clear that is expected to create the user on the system with the given uid/gid. Personally, I missed that step.

Why would that make problems when switching to version 1.1.100 (or 101)?

That is a great question and unfortunately, we won't be able to know because we don't know what changed in the code of factorio. I took a peek and the changelog and didn't looks at anything related.

The file or path mentioned in the error message /opt/factorio/bin/x64/../../config/config.ini is not part of the host system

I /think/ you are confusing vm and containers. Docker/podman is using the user specified by the config/user when running the container. If the uid/gid does not match this is where you can enter in permission problems. If you want to get more familiar with that aspects of container, one easy experiment you can do is if you run as root and you start writing file in the mounted volume, those file will be owned by root on the host system.

Even though I can't test ist anymore myself, since we reinstalled our host server.

If you feel you want to give it another try, happy to take a look if this solution does not solve the problem :)