Strange Transmission-Daemon Configuration Behavior on Debian Linux

Question

I am running a Transmission BitTorrent client on my Raspberry Pi computer, which uses Raspbian Linux. It is up-to-date as of 6/6/19. There is some strange behavior with the settings.json configuration files that can be summarized as follows:

1. When the daemon is started by the system, as in the command sudo service transmission-daemon start, the configuration directory reported by the command transmission-remote -si is /var/lib/transmission-daemon/.config/transmission-daemon/. In that directory, there is indeed a file called settings.json which has the default settings provided by the installer through apt-get.
2. When the daemon is started by the user, pi, as in the command transmission-daemon, the configuration directory reported by transmission-remote -si is /home/pi/.config/transmission-daemon/. The settings.json file also exists there, and is again initialized to the default settings upon install.
3. When executing a command to modify the configuration file while the daemon is running, as in transmission-daemon -a "127.0.0.1, 10.0.0.*", the only file that is modified is the file contained in /home/pi/.config/transmission-daemon/. This is also the only file that is ever outputted by transmission-remote -si. This holds true regardless of how the service is started, as well as whether or not the command is run as sudo.

I have done a lot of research about this, and the above is what I found out following over 20 hours of investigating. I'm somewhat new to all of this. Here's what I've done in an attempt to fix this:

1. Reboot the system.
2. Refresh the Transmission installation by uninstalling through apt-get, doing an update then an upgrade, removing all downloaded files associated, then redownloading and reinstalling through apt-get.
3. Followed installation directions from help.ubuntu.com/community/TransmissionHowTo exactly, including adding the pi user to the debian-transmission user group.

Obviously, since I am asking this question, none of these things worked. Here are my questions:

1. Is this normal behavior? If so, what is the intention behind this?
2. How can this be changed so that the configuration directory reported by transmission-remote -si is the directory that is read from and modified using configuration commands?

Answer 1

Is this normal behavior? If so, what is the intention behind this?

It's normal. Transmission-daemon was not created as a "global", system-wide service: it acts as a per-user service. Just as with the regular Transmission app, each user can have their own instance of transmission-daemon running with their own settings.

(And unfortunately it doesn't have a good command-line tool for changing certain options, especially those controlling RPC access itself. Your -a <addresses> command doesn't actually tell the running daemon to update its configuration: it starts a whole new daemon instance. So you needn't and shouldn't have the daemon already running while doing so.)

So for those who still want to manage transmission-daemon via systemctl or service, your Linux distribution creates a dedicated user account for it, and puts some initial settings in that account's home directory. The Transmission "system service" still acts and behaves like it's running under a normal user account, and it stores settings in that account's home directory.

(Note the words "dedicated user account". Not "root". Not sudo. If anything, it would be sudo -u transmission or sudo -u transmission-daemon, whichever your distro chose.)

How can this be changed so that the configuration directory reported by transmission-remote -si is the directory that is read from and modified using configuration commands?

Run those configuration commands in exactly the same environment as the daemon itself has.

• Make sure you sudo to the correct user account.

  Its name can be found from systemctl cat transmission-daemon in the User= line.

• Make sure sudo does not preserve environment variables that'd mention your own home directory, such as $HOME or $XDG_CONFIG_HOME. Try sudo -u <user> printenv; if you see /home/pi mentioned in there, that's why transmission-daemon looks there.

  Probably the most leakproof method would be to ask systemd to run the command like it runs services:

  sudo systemd-run --uid="transmission-daemon" transmission-daemon -a "127.0.0.1, 10.0.0.*"