Closed BloodBlight closed 1 year ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
That isn't a valid variable for our container.
Scratch that, I didn't realise that feature was added.
It also appears to be impacting Sonarr
A work around to this is to manually add the following line to the config.xml file after creation:
<Port>7880</Port>
Jonny's initial comment is correct, we do not, and have not used a "p" environment variable.
Jonny's initial comment is correct, we do not, and have not used a "p" environment variable.
It's in the documentation under the parameters section: https://hub.docker.com/r/linuxserver/radarr
And it was working a while back...
-p is not a environment variable
I see what you are saying!
Weird. I have deployed at least a dozen times using that and could sworn that used to work... I must be crazy and/or just forgot fixing it! ^__^
This would be a nice feature when deploying multiple instances in a composer on a single network.
Is there an existing issue for this?
Current Behavior
When creating a NEW instance of radarr, the "p" variable doesn't seem to be respected by the instance. Already created instances are not effected.
Expected Behavior
Should see the port request variable acked in the logs and the service starting on that port. Neither happen. Note that the UID and GID are being picked up correctly.
Steps To Reproduce
Create container with the config below and watch the logs.
Environment
CPU architecture
x86-64
Docker creation
Container logs