Force User/Group

[edanfalls]

I've just installed SABnzbd on my Ubuntu storage server and I'm really impressed with it so far. 

I have a few questions which I haven't been able to find the answer to elsewhere:

1. Is there some way to force the user & group of the downloads? I am running SABnzbd as "user1" and so the downloads are saved with "user1:user1" ownership. The storage server is accessed by anyone in the group "group1", so I would like to be able to save the downloads with "user1:group1" permissions instead. I can just set the download permissions to 777 to make them accessible to everyone, but would prefer to restrict by group if possible.

2. The "Permissions for completed downloads" setting is very useful. But is there some way to do the same for all the download directories? Sometimes I might want to peak inside the incomplete or cache directories myself.

3. Any reason why it was written in Python?!  I develop in Python a bit myself and I'm quite fond of it but it's awful for multithreading and so I wouldn't have thought it would be ideal for this. CPU usage does indeed seem to be high when downloading compared to other usenet grabbers.

(1) and (2) could be solved with simple shell scripts in the "Post-Processing Scripts Folder" of course, but I'd prefer a cleaner way if possible.

Thanks.

[shypike]

1.
No. I remember something called a sticky bit, that lets new folders and files inherit permissions.
My Linux knowledge is limited. Windows solves this in a more practical way.

2.
Same answer as above. Just create those folder yourself and setup some from of inheritance.

3.
It started as an experiment by the original author.
Python is a beautiful language, but far from ideal for this application.
We're especially not impressed by its TCP/IP l library and memory manager.
This is what we have and its time-consuming enough as it is.
No plans for re-writing it in C++ (yuck).

[jcfp]

1. Is there some way to force the user & group of the downloads? I am running SABnzbd as "user1" and so the downloads are saved with "user1:user1" ownership. The storage server is accessed by anyone in the group "group1", so I would like to be able to save the downloads with "user1:group1" permissions instead.

Files saved are owned by the user and (primary) group the app runs as. Both can be manipulated, the details depend a bit on your setup. If you're using the init script from the Ubuntu package, you could try setting USER=user1:group1 in /etc/default/sabnzbdplus (chmod syntax, may require user1 to be a member of group1) (won't work in 0.5.6 without modifications to the script). Other options include making group1 the primary group of user1; using sgid bit on relevant directories to inherit group ownership of files created in them (chmod g+s ); or using a postprocessing script with a simple chgrp command (once again, may require the user to be a member of the relevant group).

btw: sticky bit on a directory in linux (as commonly used on /tmp) prevents stuff from being deleted by anyone but the owner (or superuser), afaik it is not a way to inherit ownership.

[edanfalls]

Other options include making group1 the primary group of user1; using sgid bit on relevant directories to inherit group ownership of files created in them (chmod g+s ); or using a postprocessing script with a simple chgrp command (once again, may require the user to be a member of the relevant group).

btw: sticky bit on a directory in linux (as commonly used on /tmp) prevents stuff from being deleted by anyone but the owner (or superuser), afaik it is not a way to inherit ownership.

Thanks - I used sgid and it works great. As well as doing a "chmod -R g+s" to the root download directory, I had to set the sgid in the SABnzbd settings too. I set "Permissions for completed downloads" to 2770 instead of just 770 which i had before.

I found this a bit strange because as a test I did chmod g+s to a directory "dir1", then I created "dir2" inside. "dir2" correctly inherited the group. Then I did a "chmod 770 dir2" and it correctly came out as drwxrws--- ; so it kept the sgid even though I did a chmod 770 instead of 2770.

So you would expect that if I do "chmod -R g+s" to the root download directory, then "Permissions for completed downloads" could just be 770 rather than 2770. But when it's 770, subdirectories then become drwx--S-- (note the capital S), which doesn't make sense to me.

Confusing, but at least it works with 2770.

It started as an experiment by the original author.
Python is a beautiful language, but far from ideal for this application.
We're especially not impressed by its TCP/IP l library and memory manager.
This is what we have and its time-consuming enough as it is.
No plans for re-writing it in C++ (yuck).

Ah I see. Yeah definitely not ideal but I can understand that it started as a home project. I always begin everything in Python, but as soon as the subprocesses become messy it starts to struggle for speed.

Thanks for the help guys.

[absteeve]

Hey, look at me digging up this 7 year old thread...

well, it pretty much exactly mirrored a problem I'm having today, so I thought this was the best way to get this perhaps looked at.

As edanfalls points out, using 2770 incorrectly applies the setgid ("S") bit to files. FYI, the capital S is there to signify that it is an illogical use of the setgid bit. 2770 is the correct octal for FOLDERS ("correct" for those trying to achieve what edanfalls and myself are), but 0770 is correct for FILES (actually 0660, but the documentation seems to state that SAB automagically makes that adjustment).

Unfortunately, sab doesn't give us a way to distinguish between the two. "folders vs files" isn't technically the measure... what matters is if the file (or folder) is intended to be executable or not (and folders always are). But I can't imagine a different use-case other than what edanfalls and I are trying to do, so perhaps just looking at it as "folder vs file" is simplest.

I'd basically check to see if the user put a 2XXX instead of 0XXX or simply XXX, and if they did then apply that 2 for folders but not for files.

Or... perhaps simpler and more flexible is to give us a little more control by splitting the existing option into:

Permissions for completed downloaded FILES (eg. 644)
Permissions for completed downloaded FOLDERS (eg, 755)



Pretty pretty please?