We welcome all PR’s though this doesn’t guarantee it will be accepted.
Description:
I bumped into an issue that the new UMASK environment variable did not seem to work for the NZBGet service. The UMask was always 022.
4 years ago (so long before the UMASK env var) commit 64dc5f4cf9edb516dd3fb95b6f143c338291e9d6 added a line in the nzbget service run file to set the UMask to 022. I could not find a reason for this change. #26 doesn't give more information.
This static UMask got applied after the env var UMask got applied.
This PR removes the static UMask. This results in:
UMASK env var is filled: The configured UMask is applied.
UMASK env var is empty: The default UMask of the default abc user in the container is used. This is 022.
Benefits of this PR and context:
This PR fixes a bug for users that have configured a UMask using the environment variable. Users that have not configured a special UMask get the default 022, just like before. That should make the change safe for everyone.
How Has This Been Tested?
I started a container using the following docker-compose.yml service snippet:
Next I started a download and enter a shell in the container. There I ran the commands described in the Discord conversation below to check the UMask of the currently running nzbget and unrar processes.
I test this by connecting to the container using sudo docker exec -it nzbget /bin/bash and then running grep '^Umask:' "/proc/12345/status" where 12345 is the PID of the /app/nzbget/nzbget process. (I get the PID by running ps aux)
The response I get in the nzbget container is Umask: 0022.
I also tried running it in the rutorrent container, where I get Umask: 0002 as expected.
j0nnymoe
@JorisMolnar you can set the UMASK via the nzbget settings I believe aswell
JMolnar
I noticed the following file always sets the umask to 022, but I don't know if there is some other system that should change it again: https://github.com/linuxserver/docker-nzbget/blob/master/root/etc/services.d/nzbget/run
Thanks @j0nnymoe, I'll take a look at that.
I found the setting in nzbget and can confirm that works :smile:
Thanks
The original setting was 1000, which nzbget says disables changing the umask, so it seems there still is an issue with the nzbget image. But at least there is a workaround :slight_smile:
JMolnar
Regarding that umask issue I mentioned 2 hours ago, it seems like we aren't completely there yet.
NZBGet just extracted something and it had the wrong permissions.
I'd have to test further, but it's probably because the unrar process doesn't inherit the umask configured in nzbget settings. So unrar got 022 again :sweat_smile:
I'll take a look if I can spot the difference between the containers where the umask env variable works and doesn't work.
JMolnar
I think I fixed the issue. If my test succeeds I'll submit a pull request.
We welcome all PR’s though this doesn’t guarantee it will be accepted.
Description:
I bumped into an issue that the new UMASK environment variable did not seem to work for the NZBGet service. The UMask was always 022.
4 years ago (so long before the UMASK env var) commit 64dc5f4cf9edb516dd3fb95b6f143c338291e9d6 added a line in the nzbget service run file to set the UMask to 022. I could not find a reason for this change. #26 doesn't give more information.
This static UMask got applied after the env var UMask got applied.
This PR removes the static UMask. This results in:
abc
user in the container is used. This is 022.Benefits of this PR and context:
This PR fixes a bug for users that have configured a UMask using the environment variable. Users that have not configured a special UMask get the default 022, just like before. That should make the change safe for everyone.
How Has This Been Tested?
I started a container using the following docker-compose.yml service snippet:
Next I started a download and enter a shell in the container. There I ran the commands described in the Discord conversation below to check the UMask of the currently running nzbget and unrar processes.
Source / References:
The following is the short Discord discussion I had about this subject.
JMolnar Hi, I'm trying to configure the umask for my nzbget container as described here: https://github.com/linuxserver/docker-nzbget#umask-for-running-applications But it seems like this setting doesn't work.
I test this by connecting to the container using
sudo docker exec -it nzbget /bin/bash
and then runninggrep '^Umask:' "/proc/12345/status"
where 12345 is the PID of the /app/nzbget/nzbget process. (I get the PID by runningps aux
) The response I get in the nzbget container isUmask: 0022
. I also tried running it in the rutorrent container, where I getUmask: 0002
as expected.My docker-compose service snippet is:
j0nnymoe @JorisMolnar you can set the UMASK via the nzbget settings I believe aswell
JMolnar I noticed the following file always sets the umask to 022, but I don't know if there is some other system that should change it again: https://github.com/linuxserver/docker-nzbget/blob/master/root/etc/services.d/nzbget/run Thanks @j0nnymoe, I'll take a look at that. I found the setting in nzbget and can confirm that works :smile: Thanks The original setting was 1000, which nzbget says disables changing the umask, so it seems there still is an issue with the nzbget image. But at least there is a workaround :slight_smile:
JMolnar Regarding that umask issue I mentioned 2 hours ago, it seems like we aren't completely there yet. NZBGet just extracted something and it had the wrong permissions. I'd have to test further, but it's probably because the unrar process doesn't inherit the umask configured in nzbget settings. So unrar got 022 again :sweat_smile: I'll take a look if I can spot the difference between the containers where the umask env variable works and doesn't work.
JMolnar I think I fixed the issue. If my test succeeds I'll submit a pull request.