Why doesn't SABnzbd play nice with NFS ACLs?

[sofakng]

I'm using SABnzbd and storing files on an NFS share (ZFS).

I'm new to Unix/Linux access control but it appears as though SickBeard is creating files using "trivial" ACLs instead of the default NFS ACL.

For example, if I create a directory manually on my NFS share it has the following ACL:

Code: Select all

drwxrwxrwx+  2 1000     1000           3 Jun 27 11:47 test-ufs
     0:user:root:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit
         /inherited:allow
     1:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /synchronize:file_inherit/dir_inherit/inherited:allow

However, when SABnzbd creates a directory it looks like this:

Code: Select all

drwxrwxrwx   2 1001     1001           7 Jun 27 08:21 c
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow
     2:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

You'll notice the lack of a "+" next to the directory indicating that it's only using "trivial" permissions.  I'm not sure why SickBeard is creating directories (and files) using a different permission than the default NFS permission...

Can anybody help me out?

[shypike]

The only thing SABnzbd (and SickBeard) knows is the concept of the traditional Unix permission flags.
Anything else is created by the OS.

[sofakng]

Ooops - I'm sorry for mixing Sickbeard and SABnzbd in the original post.  I was only talking about SABnzbd.

Anyways... maybe the Python I/O API performs differently than the OS I/O API because otherwise I'm really not sure why the permissions are different when I manually create a directory so something is definitely different.

Is it possible to apply a user script to all downloads to fix the permissions?  Could this be triggered before the SickBeard script?  (for downloads that apply)

[shypike]

You can fix it with a script if you know how.
Just make sure that your script calls the SickBeard script at the end
with the same parameters that it received.
BTW: SickBeard will have the same issue, because it's written in Python too.

[ljw1]

I also have this problem. Any file created by sabnzbd does not inherit the file permissions of the folder it was created in. Could you please explain how the files are created then so then maybe a patch can be made to allow for the files to be created in the same way as the underlying os.

PS Did you have any success with creating a script that creates the correct acls?

[shypike]

It just opens the file with defaukt permissions and lets the OS determine what happens.
Optionally you can have it set the Unix style permissons afterwards. Config->General

[Sleepie]

I have the same problem running OpenIndiana.
Files and folders created by SABnzbd (and indeed SickBeard too) do not inherit the permissions from the parent folder.

Did anyone find a solution for this problem yet?
Maybe a script ... maybe new(er) python version?
I'm running python2.6 at the moment.

[shypike]

I'm sorry, SABnzbd will only do Posix style permissions.
We refuse to get lost in all the different file system tastes that the Linux world has.
Don't NAS filesystems have automatic inheritance like mainstream OSses have?