51 minutes ago, Jaytie said:

It would be really great if you could merge the newest version 3.4.0 to your container!

The container is self maintaining, please restart the container and it should pull the new version.

Hi, the pal world docker container is unplayable since the recent pal world core game updated. When trying to connect to the docker container the core says the game version is incompatible and wont allow the connection. I have since: restarted (several times) deleted the docker and reinstalled. Deleted my core game and reinstalled as well! This stinks! I was really excited to play my game on my server and now i cant

The dev: thijsvanloef has the up-to-date docker for pal world but the issue with it is that it writes over the palworldsettings.ini file on each boot......

1 hour ago, Braus said:

I have since: restarted (several times) deleted the docker and reinstalled.

Please do that, it's a different game (Avorion) but it applies here too:

BTW: you are in the wrong support thread, you can go to the support thread by clicking on the Docker icon within Unraid and click Support.

How do I get the header back?

19 minutes ago, socbutter said:

How do I get the header back?

The header?

Try to open the menu on the left hand side by clicking the arrow then click on the gear icon and at Scaling select Server side scaling.

6 minutes ago, ich777 said:

The header?

Try to open the menu on the left hand side by clicking the arrow then click on the gear icon and at Scaling select Server side scaling.

Can not find Server side scaling

5 hours ago, socbutter said:

Can not find Server side scaling

But I bet you can find Scaling Mode, sorry I can only offer you screenshots in German:

Are you not supporting the Lidarr container anymore? It has been saying that there is a new version update for quite awhile now and i havent seen an update for the docker image for as long as i can remember ;) just checking!

-Wes Magyar-

5 hours ago, wesmagyar said:

just checking!

Thanks for the report, I assume it has something to do because the maintainers changed and maybe they changed how their endpoints for getting the version.

5 hours ago, wesmagyar said:

i havent seen an update for the docker image for as long as i can remember

That's normal because my containers are self maintaining and they check for updates on each container restart so to speak updates from the containers are not needed often.

EDIT: I've updated the container and made a few improvements, but I have to say everything is working over here just fine.
What LIDARR_REL are you using? Make sure you've set it either to latest or nightly.

5 hours ago, ich777 said:

Thanks for the report, I assume it has something to do because the maintainers changed and maybe they changed how their endpoints for getting the version.

That's normal because my containers are self maintaining and they check for updates on each container restart so to speak updates from the containers are not needed often.

EDIT: I've updated the container and made a few improvements, but I have to say everything is working over here just fine.
What LIDARR_REL are you using? Make sure you've set it either to latest or nightly.

currently i have it set to nightly and it just updated overnight. right now its on version "3.0.1.4858" but it had been sitting on an older release for awhile. not sure which one it was as i hadn't taken note of it, and it has since updated. Thanks for the quick response! I have my docker images reset each night and a ZFS Mirror made of them so they restart nightly that could explain why i hadn't seen an update for them in awhile on the docker UI, i did not know that they could update themselves like that.

Edited October 29, 2025Oct 29 by wesmagyar
Clarity

Today, I was prompted to update Lidarr, which I did, of course, and now I am getting the following message:

/opt/scripts/start-server.sh: line 4: curl: command not found

---Ensuring UID: 99 matches user---

---Ensuring GID: 100 matches user---

---Setting umask to 0000---

---Checking for optional scripts---

---No optional script found, continuing---

---Taking ownership of data...---

---Starting...---

---Can't get latest version of Lidarr, putting container into sleep mode!---

What happened, and will it be fixed?

13 hours ago, Roddi said:

What happened, and will it be fixed?

Thank you for the report, I pushed another container update.

BTW, can you please check if something eats up your GitHub API calls in your network? The container uses now the GitHub API to determine the latest version, I might revert that back to like it was before.

 I tried the update, but unfortunately there was no improvement. The output looks like this:

lade Image: ghcr:io/ich777/lidarr_latest

IMAGE ID [1173329]: Pulling from ich777/lidarr.
Status: Image is up to date for ghcr.io/ich777/lidarr:latest
INSGESAMT ABGERUFENE DATEN: 0 B

Stoppe Container: Lidarr

Der Container wurde erfolgreich beendet: Lidarr

Container wird entfernt: Lidarr

Der Container wurde erfolgreich entfernt: Lidarr

Befehlsausführungdocker run
  -d
  --name='Lidarr'
  --net='bridge'
  --pids-limit 2048
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Odin"
  -e HOST_CONTAINERNAME="Lidarr"
  -e 'LIDARR_REL'='latest'
  -e 'CONNECTED_CONTAINERS'=''
  -e 'UID'='99'
  -e 'GID'='100'
  -e 'UMASK'='0000'
  -e 'MONO_START_PARAMS'='--debug'
  -e 'DATA_PERM'='770'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8686]/'
  -l net.unraid.docker.icon='
  -p '8686:8686/tcp'
  -v '/mnt/cache/appdata/lidarr':'/lidarr':'rw'
  --restart=unless-stopped 'ghcr.io/ich777/lidarr'
Der Befehl wurde erfolgreich ausgeführt!

After running it, the same error occurs as already described. I can't find anything unusual, unless you can tell me step by step how to check it. Then I'll do that and report back with the results.

3 minutes ago, Roddi said:

 I tried the update, but unfortunately there was no improvement. The output looks like this:

What does the log say?

Please execute this command from a Unraid terminal and post the output:

curl -s -I https://api.github.com/meta | grep x-ratelimit

curl -s -I https://api.github.com/meta | grep x-ratelimit

x-ratelimit-limit: 60

x-ratelimit-remaining: 57

x-ratelimit-reset: 1761831909

x-ratelimit-resource: core

x-ratelimit-used: 3

38 minutes ago, Roddi said:

curl -s -I https://api.github.com/meta | grep x-ratelimit

x-ratelimit-limit: 60

x-ratelimit-remaining: 57

x-ratelimit-reset: 1761831909

x-ratelimit-resource: core

x-ratelimit-used: 3

That's really strange, your GitHub Rate limit looks normal and I also can see that you used two (please note that even this command counts as one request).

Do you maybe have some Unifi hardware on your network or any AdBlocking? Please make sure that you don't block access to the GitHub API and or go through your network logs after starting the container.

Do you also have the log output from the container after starting it?

However I'll push another update shortly where I change back to the old method of getting the versions.

I don't know if it's because of the new update to the container that I just did again or if they've already made the change, but now the update ran and the container starts “normally” without any error messages.

Thank you for your help with this problem 👍. There should be more support like this.

Edited October 30, 2025Oct 30 by Roddi

Hello and Grias di @ich777 ,

First of all thank you for your great work. I love your containers.

However since upgrading to the latest 7.2.0 (and updating the containers) i ran into some weird problems with SABNZB...
For some reason the container can no longer write to the dirs i have configured... before that it was working for months without issues... I even tried to nuke the permissions on that path (chmod 777) but i still cannot create files/dirs in that container...

If i do that in Unraid it works without an issue... any idea what could be the culprit?

When i start the container i get following error:

2025-11-01 18:13:15,901::INFO::[__init__:466] SSL version = OpenSSL 3.5.1 1 Jul 2025
2025-11-01 18:13:15,917::INFO::[notifier:166] Sending notification: Warning - /data/usenet/incomplete is not writable at all. This blocks downloads.
To prevent all helpful warnings, disable Special setting 'helpful_warnings'. (type=warning, job_cat=None)
2025-11-01 18:13:15,917::WARNING::[misc:96] /data/usenet/incomplete is not writable at all. This blocks downloads.
To prevent all helpful warnings, disable Special setting 'helpful_warnings'.
2025-11-01 18:13:15,927::WARNING::[misc:96] /data/usenet/complete is not writable at all. This blocks downloads.

Edited November 1, 2025Nov 1 by tmodev
Extend

1 hour ago, tmodev said:

For some reason the container can no longer write to the dirs i have configured... before that it was working for months without issues... I even tried to nuke the permissions on that path (chmod 777) but i still cannot create files/dirs in that container...

That's not the default path in my container, you should use /mnt/downloads or at least a folder in the /mnt folder inside the container.

I have never tried other paths, I assume the /data folder is not owned by 99:100 at least that's what I suspect.

Just now, ich777 said:

That's not the default path in my container, you should use /mnt/downloads or at least a folder in the /mnt folder inside the container.

I have never tried other paths, I assume the /data folder is not owned by 99:100 at least that's what I suspect.

yes i set it up according to the trash guides.... which was working for months tho.. ill try checking the ownership of that path

Edited November 1, 2025Nov 1 by tmodev

Just now, tmodev said:

yes i set it up according to the trash guides.... which was working for months tho.. ill try checking the ownership of 99:100

Yes please, you can usually use whatever path you want in the container, but I suspect the owner and group is wrong, however I can also add another check that sets the permissions for a folder named /data in the container if it exists, this would be not a huge deal.

However in my containers it should look like this:

2 minutes ago, ich777 said:

Yes please, you can usually use whatever path you want in the container, but I suspect the owner and group is wrong, however I can also add another check that sets the permissions for a folder named /data in the container if it exists, this would be not a huge deal.

However in my containers it should look like this:

So if i got this right   ill create 2 path variables:   
- /mnt/user0/data/usenet/incomplete->  /mnt/incomplete   
-  /mnt/user0/data/usenet/complete -> /mnt/downloads

That might resolve my issue right? 

UPDATE: it did not. do i need to change ownership on the host?

Edited November 1, 2025Nov 1 by tmodev

13 minutes ago, tmodev said:

So if i got this right   ill create 2 path variables:   
- /mnt/user0/data/usenet/incomplete->  /mnt/incomplete   
-  /mnt/user0/data/usenet/complete -> /mnt/downloads

Something like that should do it.

14 minutes ago, tmodev said:

UPDATE: it did not do i need to change ownership on the host?

Usually not, however I'll implement a check for /data (but without recursion because I don't want to destroy any permissions if there are any other) :

https://github.com/ich777/docker-sabnzbd/blob/master/scripts/start.sh#L27-L29

The updated container will be available in a few minutes, however if something else changes the permissions/owner then this might be the culprit.

However, it's best to do it on the host because the container by default uses 99:100

44 minutes ago, ich777 said:

Something like that should do it.

Usually not, however I'll implement a check for /data (but without recursion because I don't want to destroy any permissions if there are any other) :

https://github.com/ich777/docker-sabnzbd/blob/master/scripts/start.sh#L27-L29

The updated container will be available in a few minutes, however if something else changes the permissions/owner then this might be the culprit.

However, it's best to do it on the host because the container by default uses 99:100

So i forced 99:100 on my path and even re-nuked the permissions to 777 but still get the same issues with the newest container

18 minutes ago, tmodev said:

So i forced 99:100 on my path and even re-nuked the permissions to 777 but still get the same issues with the newest container

So i just noticed its probably not a sabnzb issue, but an unraid issue related to the 7.2.0 update... not a single path that is passed through to any container is currently writeable inside the container... thanks for looking into it and trying to help out