Error with v.5.1.0

[viriatusX]

With the new version, the docker does not start. It stops automatically, with this error:

[oschwald]

As of 5.1.0, the image no longer runs as the root user by default. It sounds like there is a permission issue writing to the volume in your case. Are you bind mounting a directory on the host? Would you be able to provide more details about your configuration and how you are running the image?

If you want to continue using the root user in the image, you could run it with the --user 0 flag.

[viriatusX]

I use geo2ip in unraid. I have mapped the folder correctly.

[masterwishx]

having same issue in Unraid in latest version

[masterwishx]

@viriatusX Fixed by changed permission in folder to 1000:1000 instead of root like @oschwald said :
chown 1000:1000 .geoipupdate.lock
chown 1000:1000 *

[viriatusX]

Solved with this. Thanks :)

[Bosh-StocksDigital]

I am facing the same issue in AWS ECS, is this considered a bug?

[masterwishx]

, is this considered a bug?

no ,please read above ....

[I70l0teN4ik]

My scheduled pipeline in gitlab CI to fetch latest DB failed with 5.1 it seems a bit concerning to me:

Using docker image sha256:2cfbbe399e410c58d66d43a87677eaff06a7ca7e9d9afac1b004c9d9ce1472d8 for maxmindinc/geoipupdate:latest with digest maxmindinc/geoipupdate@sha256:e7ab311bbffab2b341565ea9512259be844f0e5dda038ea903e44ca88b05a144 ...
$ /usr/bin/entry.sh
# STATE: Creating configuration file at /var/lib/geoipupdate/GeoIP.conf
# STATE: Running geoipupdate
geoipupdate version 5.1.0
Using config file /var/lib/geoipupdate/GeoIP.conf
Using database directory /usr/share/GeoIP
Initializing file lock at /usr/share/GeoIP/.geoipupdate.lock
error retrieving updates: error acquiring file lock: error acquiring file lock at /usr/share/GeoIP/.geoipupdate.lock: open /usr/share/GeoIP/.geoipupdate.lock: permission denied

I do not mount any volumes explicitly not even sure what't the proper fix now 🤔
In my CI job I'm just setting the env vars and use downloaded file as an artifact in later stages. That's actually how I'd expect it to work.

[oschwald]

Based on the feedback, we will be reverting the change to use a non-root user within the container. For now, we will leave the code to support running the container as UID 1000 if you specify that. In the future, we may support a step-down approach where the UID and GID can be specified via an environment variable or we may provide two separate images, one that uses root and one that doesn't. Feedback on either of these approaches would be welcomed.

[oschwald]

5.1.1 has been released.