Help with docker sabnzbd install/permissions

[Deleted member 5784]

yes they do already exist, have existed for quite some time, as other containers refer to them.
is this a recent change as surely it should be clever enough to check if they exist before trying to create them again.

Don't know the history of Sab internals, or what assumptions the devs had in this area; i'm just suggesting a possible cause of your error.

won't that then create issues with other containers that need them?

I've no idea; it depends what those other containers are & what they're expecting etc. You'll have to run this scenario for yourself.
Just rename the top level /usenet/ folder to, say, /xusenet/ temporarily while you try my suggestion; then just rename it back when you're done testing. Or even simpler, specify a non-existing new folder in the Sab dialogue, just as a test of my suggestion. Specify it as '/foo/bar' and see if this works...

 

[chenks]

just tried pointing it to a folder that doesn't yet exist - same error "cannot create directory"

clicking on the "browse" icon, i can't see anything outside of the root of the container

 

[Deleted member 5784]

Are you absolutely sure that user with PUID 1026 has all nec read / write / exec permissions on the /volume1/data/downloads/ dir?

 

[chenks]

PUID 1026 definitely has r/w permissions, as i'm using the same PUID/PGID in another container that has r/w permissions to the same volume/folder.

in fact PUID 1026 is the only user on the NAS, which is the only user that has r/w to the volume.

it definitely feels like a user permission issue, but can't see why.

 

[Deleted member 5784]

Agree it's almost def a permissions issue.

I'm running Sab on a Linux server rather than a Syno, so am using a docker compose file to configure my Sab rather than the Syno GUI. My compose file doesn't use the 'HOME' parameter that you have in your GUI...try temporarily deleting this param and see if this changes what's visible when you 'Browse' in the Sab folders dialogue.

Put the param back in after trying this.

 

[chenks]

the HOME parameter was there as part of the docker creation - it's also there on sabnzbd running on my pi.
removing it made no difference

-- post merged: 16. May 2023 --

as an example, here's another container that runs with with no issues, using the same volume mount point

that one has 101 as the PGID, but i tried that as well as 100 and it made no difference to the error message

 

[Deleted member 5784]

...different Group ID to your Sab container: 100 vs 101... (posted b4 yr edit)

-- post merged: 16. May 2023 --

You said this 2nd container has the same volume mount point as Sab container; this isn't clear in yr screengrab. The /config mount is implied there, but not the /downloads mount. I'm not doubting you; just trying to be systematic.

 

[chenks]

i didn't show the mount points in the image above, just the environment variables.

both this sab container and the container example above, have mount points pointing to the exact same location.

-- post merged: 16. May 2023 --

and

 

[dimfil]

i didn't show the mount points in the image above, just the environment variables.

both this sab container and the container example above, have mount points pointing to the exact same location.

-- post merged: 16. May 2023 --

View attachment 12763

and

View attachment 12764

In your sabnzbd settings you have mapped existing data folder to /downloads mount path.
Therefore in sabnzbd settings you have to use also "/downloads" when pointing to folders e.g. /downloads/usenet/incomplete instead of /usenet/incomplete alone.
As it is now, sabnzbd tries to create a folder somewhere that cannot understand...

Assuming that your existong folder is /volumes1/data/downloads/usenet/incomplete then I would suggest to correct mappings as follows:

docker/sabnzbd --> /config
data/downloads/usenet --> /downloads
data/downloads/usenet/incomplete --> /incomplete-downloads

That should do the job but I believe you have to reset the container for the changes to take effect...

 

[chenks]

That should do the job but I believe you have to reset the container for the changes to take effect...

just tried as you suggested, but still the same error

so i changed the mount point for /downloads to data/downloads/usenet
reset the container, started it

loaded sabnnzbd
tried setting the "Completed Download Folder" to "/downloads/complete" - "Cannot create directory /downloads/complete"

 

[dimfil]

That's absolutely weird...

Delete and start over using this guide...

 

[chenks]

Delete and start over using this guide...

it was actually created using parts of that guide (with the exception of the network part which isn't relevant)

i do notice that guide uses a mount path called /data/usenet, which isn't part of the official container notes, which says you should use /downloads (which is what i've used on the sabnzbd container running on my pi).

i'm pretty sure this is some sort of weird permissions issues, as i've had sabnzbd running on the NAS just fine before.

 

[Rusty]

Personally I use the following compose and it works just fine (PID/GID needs to be changed, as well as optional port, and volumes) with no issues at all at any point

version: "2.1"
services:
  sabnzbd:
    image: linuxserver/sabnzbd:latest
    container_name: sabnzbd
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Paris/Zagreb
    volumes:
      - /volume1/docker/sabnzbd:/config
      - /volume1/downloads/:/downloads #optional
      #- /path/to/incomplete/downloads:/incomplete-downloads #optional
    ports:
      - xxxx:8080
    restart: unless-stopped

 

[dimfil]

The folder paths and mapping can be different if you follow exactly the guide, no problem about that.
I followed guides from there and everything is working as expected that's why I suggest to have a look if you need further help.
From what information you have already provided, you should be OK by now if no other permission issues exist.

 

[chenks]

Personally I use the following compose and it works just fine (PID/GID needs to be changed, as well as optional port, and volumes) with no issues at all at any point

essentially identical to how mine was created.
as i said, i don't believe this to be a docker/container issue, almost certainly a permissions issue, but what that issue is i don't know

the PUID and PGID i'm using is 100% correct (and the same as used by other containers with rw permissions to the same location)

From what information you have already provided, you should be OK by now if no other permission issues exist.

as above, has to be a permission issues, not a docker/container issue.

 

[Rusty]

permissions issue

Have you tried to crate a new DSM account (and new UID) as well as new config folder and create the SAB using those parameters?

 

[chenks]

Have you tried to crate a new DSM account (and new UID) as well as new config folder and create the SAB using those parameters?

bizarrely that has solved it, which does confirm it must have been a permission issue.
not sure why though then the original user has more permissions than the restricted docker user i just created.

edit - actually no, it still gives the error if the folder already exists, but if you remove the existing folder and let it create it again, then it works. why it has an issue using a folder that already exists i have no idea, you'd think it would have the required logic to check if it exists first before trying to blindly create it again.

 

[Deleted member 5784]

bizarrely that has solved it, which does confirm it must have been a permission issue.
not sure why though then the original user has more permissions than the restricted docker user i just created.

edit - actually no, it still gives the error if the folder already exists, but if you remove the existing folder and let it create it again, then it works. why it has an issue using a folder that already exists i have no idea, you'd think it would have the required logic to check if it exists first before trying to blindly create it again.

As per my initial replies. The wording in the error log does suggest that Sab is indeed trying to create the dirs specified in the 'Folders' tab, not just set them.

It's OS software; what you or I might consider logical / obvious is not necessarily what the devs do.