Issues with torrents and file permissions


I’ve been having a few issues with my recent switch to Stretch from Jessie (Odroid C2).

  • Deluge doesn’t download torrents - ‘no incoming connections’
  • Transmission-daemon doesn’t move files from the incomplete to complete folder (a permissions problem?)
  • qBittorrent login credentials (from dietpi-software forum) aren’t loading
  • Sonarr cannot add files previously downloaded (Jessie) from the completed torrents folder due to lack of permission
  • Attempted a bug report but received ‘[FAILED] DietPi-Bugreport | Failed to connect to SFTP server. Please try again later or report this to DietPi forum or GitHub repo in the first place.’

It was a clean install but I will re-do the install later today. I managed to save some of the bug report files from tmp before they were removed so I can send these.

Deluge services error:

root@Odroid:~# systemctl status deluge-web.service
● deluge-web.service - DietPi Deluge-web Service
   Loaded: loaded (/etc/systemd/system/deluge-web.service; disabled; vendor pres
et: enabled)
   Active: active (running) since Wed 2019-01-02 19:03:28 AEDT; 13h a
 Main PID: 1308 (deluge-web)
   CGroup: /system.slice/deluge-web.service
           └─1308 /usr/bin/python /usr/bin/deluge-web -l /var/log/deluge-web.log
 -L warning

Jan 02 19:03:28 Odroid systemd[1]: Started DietPi Deluge-web Service.
Jan 03 08:45:53 Odroid systemd[1]: [/etc/systemd/system/deluge-web.servi
ce:5] Failed to parse service type, ignoring: simple #forking causes systemd-tty
-ask-password-agent hang

root@Odroid:~# systemctl status deluged.service
● deluged.service - DietPi Deluged Service
   Loaded: loaded (/etc/systemd/system/deluged.service; disabled; vendor preset:
   Active: active (running) since Wed 2019-01-02 19:03:28 AEDT; 13h a
 Main PID: 1300 (deluged)
   CGroup: /system.slice/deluged.service
           └─1300 /usr/bin/python /usr/bin/deluged -d -l /var/log/deluged.log -L

Jan 02 19:03:28 Odroid systemd[1]: Started DietPi Deluged Service.
Jan 02 19:03:34 Odroid deluged[1300]: /usr/lib/python2.7/dist-packages/deluge/_l RuntimeWarning: to-Python converter for boost::shared_ptr<libto
rrent::alert> already registered; second conversion method ignored.
Jan 02 19:03:34 Odroid deluged[1300]:   import libtorrent as lt

Incomplete torrents permissions:

ls -l /mnt/HardDrives/Gabe/Other/Incomplete
total 12
drwxr-xr-x 6 debian-transmission dietpi 4096 Dec 27 01:01 xxxx
drwxr-xr-x 9 debian-transmission dietpi 4096 Dec 27 01:46 xxxx
drwxr-xr-x 7 debian-transmission dietpi 4096 Dec 27 01:05 xxxx

I will report whether these issues occur after fresh install. Some of these problems (permissions) may be related?


On fresh install, deluged service error still present but can download. Transmission-daemon still does not move completed files. Sonarr not tested. qBittorrent login fails.

Are you trying to move files that are downloaded to a directory not owned by the user the program is running under?

It might not be able to write to that directory

The peers drop off in Deluge and no files are written so it seems to be the case.

It’s an external drive (ext3 formatted) mounted with Fstab (used to do this manually so still do). Never had a problem with Jessie. Downloading with Deluge works to /mnt/dietpi_userdata/downloads which is owned by root. My other download folders seem to be owned by sonarr or transmission.

might change those directories to root:root owned

Be VERY careful changing the chown or chmod of directories recursively as su or root

#chown -R root:root /dir/you/want/to/change/owner

what does the sonarr or transmission programs run as?

also…the users for sonarr/transmission might not be in the tty group

Found this
Try doing a chmod on the download directory of your sonarr/transmission program

#chmod 777 /dir/of/downloads

Thanks for the suggestions WarHawk, seems to have fixed Transmission (completed downloads now move from incomplete to complete).

However, sonarr can’t import them. It works if I change the permissions to sonarr:sonarr but the default for downloaded files from Transmission is debian-transmission:dietpi.

I’ve tried ‘usermod -a -G’ for all combinations but this hasn’t worked even with 777 permissions.

Seems that a combination of changing the Transmission service files to be debian-transmission:dietpi and starting new downloads worked.

You are on current DietPi v6.19.7 currently, right?

EDIT: Hehe I read the topic from top to bottom while writing, so some of the fixes below seem to not be required anymore. However might be still useful/interesting and/or fix remaining issues :wink:.


  • About the download issue, I am currently doing a test install and check, whether downloads work fine here.
    EDIT: Download works well here, even without any incoming port opened to the test VM:
root@VM-Stretch:/mnt/dietpi_userdata/downloads# l
total 4
drwxrwxr-x 2 deluge dietpi 4096 Jan 15 20:55 XXXX
G_CONFIG_INJECT 'UMask=' 'UMask=002' /etc/systemd/system/deluged.service '\[Service\]'
systemctl daemon-reload
systemctl restart deluged
  • The error you see in systemctl status deluge-web.service is due to changes in systemd, not allowing in-line comments anymore. However, since the desired Type=simple is default anyway, this should not cause any issues, nor change anything. Simply remove the line from the systemd unit, to get rid off the error despite:
sed -i '/^Type=/d' /etc/systemd/system/deluge-web.service
systemctl daemon-reload
systemctl restart deluge-web

EDIT: Fixed for v6.20:


  • On which DietPi version did you install Transmission? Since v6.17 it runs as group dietpi and creates it’s downloads with correct 660/770 permissions.
  • However, AFAIK we did not apply this patch on DietPi-Update, to not mess with existing configs. Please try the following to apply permission settings to your Transmission instance:
mkdir -p /etc/systemd/system/transmission-daemon.service.d
echo -e '[Service]\nGroup=dietpi' > /etc/systemd/system/transmission-daemon.service.d/dietpi-group.conf
sed -i '/^}/d' /etc/transmission-daemon/settings.json
G_CONFIG_INJECT '\"umask\":' '    "umask": 7,' /etc/transmission-daemon/settings.json
echo '}' >> /etc/transmission-daemon/settings.json
systemctl daemon-reload
systemctl restart transmission-daemon
  • EDIT: Ah I see now you use a custom download location outside of dietpi_userdata. Please try to change ownership and permissions of the whole download location to allow dietpi full R/W access to them:
chown -R dietpi:dietpi /mnt/HardDrives/Gabe/Other
chmod -R 775 /mnt/HardDrives/Gabe/Other

This might solve the Sonarr issue as well. Future downloads are already done with correct user/group, so this should work then automatically.


  • Note that the default password dietpi is only true, as long as you didn’t change it via dietpi.txt or dietpi-config. This is only a place holder for the actual global password you applied to your system.
  • Try to used the password you initially applied to dietpi.txt before doing the first boot, or in case the global password you set during first run setup or afterwards. The prompt should have asked you for two passwords: One for the unix users, one as global defaults for dietpi-software installs, which is the one that applies here.


  • With patch to DietPi v6.18 Sonarr should have been re-installed to at latest run with correct permissions.
  • But if the files were downloaded by downloaders, before the permission changes have been applied, it might be possible that those downloads do not yet have the correct ownership.
  • Which download location do you use? /mnt/dietpi_userdata/downloads should be the default and every dietpi-software install should apply the correct ownership automatically.
  • EDIT: See above Transmission EDIT, the chown 775 and Transmission UMask 002 should grant all required permissions to Sonarr.

Bug report

  • Did you retest on fresh install on current DietPi versions? We changed our SSH domain for SFTP uploads to a sub domain, but patched that on DietPi-Update.
  • Please try: G_CHECK_URL
    If that works, but bug report still fails, try to re-apply the fix manually, but run the below only, if you are really on current DietPi version, since we changed G_CONFIG_INJECT command to not require any special char escaping anymore, which was required before:
G_CONFIG_INJECT '[[:blank:]]' ' ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDE6aw3r6aOEqendNu376iiCHr9tGBIWPgfrLkzjXjEsHGyVSUFNnZt6pftrDeK7UX+qX4FxOwQlugG4fymOHbimRCFiv6cf7VpYg1Ednquq9TLb7/cIIbX8a6AuRmX4fjdGuqwmBq3OG7ZksFcYEFKt5U4mAJIaL8hXiM2iXjgY02LqiQY/QWATsHI4ie9ZOnwrQE+Rr6mASN1BVFuIgyHIbwX54jsFSnZ/7CdBMkuAd9B8JkxppWVYpYIFHE9oWNfjh/epdK8yv9Oo6r0w5Rb+4qaAc5g+RAaknHeV6Gp75d2lxBdCm5XknKKbGma2+/DfoE8WZTSgzXrYcRlStYN' /root/.ssh/known_hosts
  • Then retry to upload a bug report or send dietpi-survey, which connects to the same SFTP server.

Hi MichaIng,

Thanks for this comprehensive response, I’ve got everything working in a round-a-bout way and will use some of this info to reconfigure my system to make it more streamlined. I have multiple download clients running in different folders and Delgue and Transmission seem to be acting a little differently. At the moment I’m stuck with nothing working following the .20 update but that is under discussion in other threads. Will let you know how I go with these edits.

The v6.20 update issues should be resolved with v6.21. If you are still stuck, exit any dietpi-software prompt, if it appears automatically on login, then:

> /DietPi/dietpi/.update_stage
echo 1 > /DietPi/dietpi/.install_stage
dietpi-update 1

I’m new to DietPI and was having issues with qBittorrent permissions. I use radarr/sonarr and qbittorrent on a headless Pi 4 torrentbox. And there is a hardlink feature in both radarr/sonarr apps which was not working. After some investigation, I found the issue was with qBittorent, which created files with 755 permissions. So radarr/sonarr don’t have write permission for downloaded files and hardlinks failed to create.
Made some search over net, found this:

So I just edited the /etc/systemd/system/qbittorrent.service file, added UMask=002 under [Service] section and after reboot everything runs flawlessly!
Think this setting should be implemented in future releases.


a fix was implemented into DietPi v6.30