0

I have created a systemd service to run deluged (v2.1.1). deluged sets permissions to no permissions when writing to any file, but UMask is set to 777. As a result, the config and session state files that it writes to while running get changed to no permissions. When stopping the service it attempts to write the session state and fails (as you can see in the logs), so the session state and any configuration changes are not saved.

This behavior is consistent across multiple fresh installations of Linux Mint 21.3 and Ubuntu Server 22.04.4 and I haven't seen any reports of this despite the fact that I've followed deluge's documentation in creating this service. What am I doing wrong?

Contents of /etc/systemd/system/deluged.service:

[Unit]
Description=Deluge Bittorrent Client Daemon
Documentation=man:deluged
# Start after network and specified mounts are available, see mount UNIT names in sudo systemctl -t>
After=network-online.target
# Won't start if these mount points are not connected
Requires=mnt-one.mount mnt-two.mount
# Stops service if mount points disconnect
BindsTo=mnt-one.mount mnt-two.mount

[Service]
Type=simple
User=deluge
Group=deluge
UMask=777


#with the custom logging
ExecStart=/usr/bin/deluged -d -l /var/log/deluge/daemon.log -L warning


Time to wait before forcefully stopped.


TimeoutStopSec=300


[Install]


Start the service when the mount points come back online


WantedBy=multi-user.target mnt-one.mount mnt-two.mount

Example of deluged's working directory (which is the deluge user's home directory) showing that the file session.state has no permissions after the session stops (the conf files would have also had these same permissions had I edited the configuration while it was running):

ls -al /var/lib/deluge/.config/deluge
total 3848
drwxrwxrwx 7 deluge deluge    4096 Feb 23 08:41 ./
drwxr-x--- 4 deluge deluge    4096 Feb 20 21:08 ../
drwxrwxrwx 2 deluge deluge    4096 Feb 23 08:41 archive/
-rwxrwxrwx 1 deluge deluge      56 Jan 28 00:05 auth*
-rwxrwxrwx 1 deluge deluge      75 Feb 23 08:08 autoadd.conf*
-rwxrwxrwx 1 deluge deluge      75 Feb 22 16:59 autoadd.conf.bak*
-rwxrwxrwx 1 deluge deluge     367 Feb 23 08:08 blocklist.conf*
-rwxrwxrwx 1 deluge deluge     367 Feb 22 17:12 blocklist.conf.bak*
-rwxrwxrwx 1 deluge deluge 3653994 Feb 22 17:12 blocklist.download*
-rwxrwxrwx 1 deluge deluge    2807 Feb 23 08:08 core.conf*
-rwxrwxrwx 1 deluge deluge    2806 Feb 23 08:08 core.conf.bak*
-rwxrwxrwx 1 deluge deluge       0 Jan 28 00:10 deluged.log*
---------- 1 deluge deluge      11 Feb 23 08:41 deluged.pid
-rwxrwxrwx 1 deluge deluge      56 Feb 23 08:08 execute.conf*
-rwxrwxrwx 1 deluge deluge     112 Feb 22 17:17 extractor.conf*
-rwxrwxrwx 1 deluge deluge     112 Feb 22 17:17 extractor.conf.bak*
-rwxrwxrwx 1 deluge deluge     252 Feb 21 07:20 hostlist.conf*
-rwxrwxrwx 1 deluge deluge     252 Jan 28 00:05 hostlist.conf.bak*
drwxrwxrwx 2 deluge deluge    4096 Jan 28 00:05 icons/
drwxrwxrwx 2 deluge deluge    4096 Jan 28 00:05 plugins/
-rwxrwxrwx 1 deluge deluge    3183 Feb 22 17:17 scheduler.conf*
-rwxrwxrwx 1 deluge deluge    3183 Feb 22 17:17 scheduler.conf.bak*
---------- 1 deluge deluge    3658 Feb 23 08:34 session.state
-rwxrwxrwx 1 deluge deluge    4386 Feb 22 16:41 session.state.bak*
drwxrwxrwx 2 deluge deluge    4096 Feb 22 16:33 ssl/
drwxrwxrwx 2 deluge deluge    4096 Feb 23 08:44 state/
-rwxrwxrwx 1 deluge deluge   84806 Feb 23 08:08 stats.totals*
-rwxrwxrwx 1 deluge deluge   84810 Feb 23 08:07 stats.totals.bak*
-rw------- 1 deluge deluge    1323 Feb 23 08:41 web.conf
-rw------- 1 deluge deluge    1323 Feb 23 08:34 web.conf.bak

My questions:

  • What am I doing wrong? I've been using systemd for years and have never seen a program do this. I followed the documentation to create the service and setup the system, and I can't find anyone with the same problem. I also had this working for quite a while before I suddenly started having this problem, and how I have it with 100% repeatability on all systems I've tested.
  • Is there a linux tool that gives me visibility into what program has changed the permissions of a file and when?
Vlastimil Burián
  • 28,462
jitter
  • 3
  • 3
    I'm confused - isn't 000 exactly what's implied by a umask of 777? Why did you choose this value specifically? – steeldriver Feb 25 '24 at 22:43
  • @steeldriver Oh maybe I'm making an error, I thought 000 was no permissions. In any case when I write 000 I mean no permissions. What is the correct notation for no permissions? I've edited my post to fix my error there. Thanks! – jitter Feb 25 '24 at 22:56
  • 1
    Sorry but deluge's documentation doesn't appear to tell to use UMask=777 in any of its multiple UMask examples. – A.B Feb 25 '24 at 23:15
  • 1
    ... indeed, you probably want a mask more like 007 as suggested at Daemon (deluged) service. FYI 000 does mean "no permissions", and that's what you get with a mask of 777 - see here for example. – steeldriver Feb 25 '24 at 23:17
  • Ah! I'm confusing the mask value with the permissions value! But the mask value is the inverse of the permissions value! This is indeed the problem. Changing to UMask=007 gives me the desired permissions of 770 (rwxrwx---). Now deluged which runs as the deluge user can now RWX the files as needed. – jitter Feb 26 '24 at 06:04

1 Answers1

0

Solution: I forgot that UMask and permissions are not the same, instead is a list of what you are not allowed to do while permissions are a list of what you are allowed to do. I build a fresh system with the corrected UMask in deluge.sessions to 007 and the issue was resolved.

Vlastimil Burián
  • 28,462