I would like to love Transmission-daemon

B

Braintrash

Hi,

I have a problem where i can't connect to Transmission's RPC.

Error is as following:

Code: 
403: Forbidden
Unauthorized IP Address.

Either disable the IP address whitelist or add your address to it.

If you're editing settings.json, see the 'rpc-whitelist' and 'rpc-whitelist-enabled' entries.

If you're still using ACLs, use a whitelist instead. See the transmission-daemon manpage for details.

I used to have Transmission-daemon working right on Ubuntu server, but I am clueless here.

My configuration was as follow:

Code: 
# pkg install transmission-daemon

# service transmission onestart
# service transmission onestop

# ee ~/.config/transmission-daemon/settings.json
(Here, I configured the file, disabling whitelist, which I never use.)

# ee /etc/rc.conf
   transmission_enable="YES"

# ee /etc/pf.conf
   (opened tcp 51413)

# pw groupmod transmission -m user

# service transmission start

I don't see where the problem lies...
 
Update, after a reboot of the server:

Code: 
409: Conflict
Your request had an invalid session-id header.

To fix this, follow these steps:

[LIST=1]
[*]When reading a response, get its X-Transmission-Session-Id header and remember it
[*]Add the updated header to your outgoing requests
[*]When you get this 409 error message, resend your request with the updated header
[/LIST]


This requirement has been added to help prevent CSRF attacks.

X-Transmission-Session-Id: TBjuBJibEi3afmeggftgu8tpTYyy05NElOqlYe9wAub8ytBv
 
Before enabling any service, you should read the service script itself. There are almost always instructions within it that tell you how to use it, or a list settings that can be configured in /etc/rc.conf.

Service/daemon scripts for ports are installed to /usr/local/etc/rc.d ;)
 
Let's recap, shall we?

Braintrash said:
I used to have Transmission-daemon working right on Ubuntu server, but I am clueless here.
Click to expand...

Okay. You are (were?) an Ubuntu user, so you're probably just not aware of how things work in *BSD-land. Here's a clue for you...

ANOKNUSA said:
There are almost always instructions within [a service script] that tell you how to use it ... Service/daemon scripts for ports are installed to /usr/local/etc/rc.d ;)
Click to expand...

But I guess you're not going to take 30 seconds to read the clearly-written instructions in /usr/local/etc/rc.d/transmission, and will instead just continue banging your head against the wall, wondering why Transmission keeps using its default settings and ignoring the configuration file it doesn't even know about. Your choice, I guess.
 
Lets keep it civilized please.

Braintrash, there's a big difference between running transmission on your user account (which probably what Ubuntu does) and running it as a service (which is what FreeBSD does).
 
Hi SirDice,

Thank you for your kind answer, I just saw it. The problem is solved (I needed to add /web/ after transmission in the URL), but I am facing another problem.

First, transmission-daemon also runs as a service with its own user (at least, it is how I always configured it) on Ubuntu and it is what I try to achieve on FreeBSD, since I believe it to be the best way.

Now, I am using ZFS, with a folder specifically made for downloads (/home/download/) with rights to transmission (chown -R transmission:transmission /home/download). With the service stopped — same than with Ubuntu, so no surprise here —, when I configure my settings.json (/usr/local/etc/transmission/home/settings.json), all my settings are kept BUT the download directory, which is reset to the default.

Maybe do you see what I am missing here?
 
I found a workaround: in /etc/rc.conf, I added a line to specify the download dir:
transmission_download_dir=""

It does the trick and everything now works as expected.

Still, I don't like it: shouldn't the value I put into the settings.json be kept, especially since ALL the other values I enter are correctly kept?

I also thought it was the directory I was using that was wrong, but tests proven the directory is working flawlessly, so it's not that.

If someone knows what I am missing here, all comments of good will are welcome. :)
 
I think what you are running into is the setting you pass on the command line (the one set in the rc.conf file or the rc.d/transmission file) is overriding your settings.json configuration. Having the command line override a configuration file is standard behaviour for most utilities.

Second, on Ubuntu it looks like you were running Transmission from a user account, not just with its own user account. Those are two separate things. On FreeBSD your post indicates you are running Transmission as a system service, not invoking it as a user, which is why the configuration is behaving differently.
 
From the start, my only change to the rc.conf file was adding
Code: 
transmission_enable="YES"
to it.

And I did it after a onestart and a onestop to have the settings.json file created and all of my configuration was done into the settings.json.
It is because the json wasn't keeping my download directory that I ended adding
Code: 
"transmission_download_dir=""
in the rc.conf. But my belief is that I shouldn't have to add this
Code: 
transmission_download_dir=""
line in the rc.conf and I haven't found anything in the docs saying my belief is wrong. :-(

I hope I make sense because I have the feeling you don't get me right (or maybe it is me whom is getting you wrong). ^^

On Ubuntu, I always used Transmission as a service, with its own user account (transmission). I always thought it was the only right way to do it. And my expectation is that, although the system files are not the same, the configuration of the transmission-daemon itself should be the same:

- Preparing a directory the transmission user/group can use.
- Configuring the settings.json after a primary start and stop.
- Declaring it as a service and starting it for good.
 
You must log in or register to reply here.
Back
Top