Managing file permissions on deluge-daemon (umask + upstart)

[Kanji_Man]

I currently run deluge as a daemon on one machine with web & gtk clients on other machines. Deluge downloads to a zfs array shared by nfs to the other machines. I've been having problems with the file permissions on the downloads when accessing them from other machines. The problem seems to boil down to my local user account not being able to access files created by the "deluge" user that deluge-daemon is using to create the files.

I followed the tutorial here (deluge-daemon using upstart under ubuntu) but I could see no way of managing file permissions or user masks. After a bunch of searching i came accross many posts indicating this needs to be handled by umask but could find no details on how to implement it. I read through the older tutorial here (deluge-daemon using initscript under ubuntu) even though at the very top it reccomends using the first tutorial since 2006. I noticed that this older method does have code to handle umask and adapted it to the first tutorial with the help of some quick manpage reference. Here is my resulting /etc/init/deluge.conf

Code: Select all

start on (filesystem and networking) or runlevel [2345]
stop on runlevel [016]

env uid=deluge
env gid=deluge
env umask=000

exec start-stop-daemon -S -c $uid:$gid -k $umask -x /usr/bin/deluged -- -d

Maybe someone can update the UserGuide with this or a better way to handle file permissions. At the very least I hope I can find this post as a reminder to myself the next time I run into this problem.

[Cas]

If you create an Trac account you can update the wiki.

There is an alternative solution of using ACLs but it is a bit more complicated to setup.

[Kanji_Man]

Trac account created and wiki updated.

[kitrule]

Great, thanks for updating the wiki! I put the first upstart script there and forgot about umask. Sorry for the inconvenience and thanks for tracking down the necessary argument.

[kitrule]

I added the umask argument to the other start-stop-daemon references in the wiki page, but I don't think deluge-web needs it because it's just a client.
Do you know if umask has any effect on deluge-web? If not I'll remove it. I notice it was in the original init script for deluge-web too.

[Kanji_Man]

I can't think of a good reason that deluge-web would need the umask. I only use the webui for basic adding and removing of torrents and go to the gtk for all my heavy lifting. As you mentioned, the older initscript used it so I included it in the newer upstart script. The only thing that comes to mind that this might affect would be adding/removing plugins from the webui but again I go to the gtk for this sort of thing.

[kitrule]

I think you're right regarding the plugin scripts and I did some testing to confirm it also affects the logs so I've expanded the guide. I don't know how ZFS and NFS would be affected but I assume adding specific users to the group deluge runs as is a more secure alternative to granting full access on deluge downloads to all accounts on the system so I've amended the defaults in the guide and described the effects of some other values. Hopefully I haven't made any mistakes.

[crazycaveman]

A less "risky" approach, in my opinion, is to set the group sticky bit on the main directory downloads are put in (chmod g+S /mnt/downloads). This will make any file or directory put under it be owned by that group (and subdirectories will also have the stick bit set) so any user of that group would be able to access the folders. That way, you can better manage who has access to your downloads

[Kanji_Man]

I like the approach of using umask 007 and adding/removing users to the "deluge" group to control access to the downloads. I've implemented the updated guide on my setup (as well as couple friends' servers) and all is working well. Thanks for the continued work on this issue.

[madhartigan]

It appears that this update has not been integrated with the wiki? Would it be ok if I incorporate it into the User Guide?