Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

I have ssh-access to my raspberry pi. I want to automate it, especially the transmission-daemon. I already set it up so I can use it manually. I have web-interface-access from every device in my network and can use android remote apps for transmission. I'm using the RPC-whitelist without problems. Except one:

I want to write some scripts to control the daemon. To control it I think transmission-remote should be the right thing (isn't it?). I can use it from any device with the daemon and it works. Except from the raspberry pi itself. This is really bad since the scripts are supposed to run on the raspberry pi (started via cron).

The hostname of my RPi is "homeserver".

I can do this on my computer (running ubuntu 12.10):

chocobai@pfubuntu:~$ transmission-remote homeserver -t all -S
homeserver:9091/transmission/rpc/ responded: "success"
chocobai@pfubuntu:~$ 

But on the raspberry something like this does not work:

pi@homeserver ~ $ transmission-remote -t all -S
Unexpected response: <h1>403: Forbidden</h1><p>Unauthorized IP Address.</p><p>Either disable the IP address whitelist or add your address to it.</p><p>If you're editing settings.json, see the 'rpc-whitelist' and 'rpc-whitelist-enabled' entries.</p><p>If you're still using ACLs, use a whitelist instead. See the transmission-daemon manpage for details.</p>uments":{},"method":"torrent-stop"}

pi@homeserver ~ $ 

Now you may want to see my RPC-settings from the settings.json. I rebooted and restarted the daemon already several times. I also tried different things in the whitelist. Now here the RPC settings:

"rpc-authentication-required": false,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": "{e8ca1abb0e2ed100615b48009bcc935b50e6404c2Nge2Ql1",
"rpc-port": 9091,
"rpc-url": "/transmission/",
"rpc-username": "",
"rpc-whitelist": "192.168.178.*,localhost,172.0.0.1",
"rpc-whitelist-enabled": true,

I'm sure it uses the right settings.json because otherwise the other accesses would still not work. Also it's the standard file in ~/.config/transmission-daemon/settings.json.

A second little problem which is maybe related: When I sudo reboot the RPi, the transmission-daemon starts, but is not accessible via web or apps. Then I make sudo killall transmission-daemon and start it just using transmission-daemon. I'm not sure why this is. There is no different user or something. Maybe it's something with permissions on the settings.json? I'm not that experienced and can't figure out which permission the daemon has when started after reboot. I don't even know why it gets started automatically.

pi@homeserver ~/.config/transmission-daemon $ ls -l | grep settings
-rw------- 1 pi pi 2211 Jan 21 22:55 settings.json
pi@homeserver ~/.config/transmission-daemon $ 

So this is my problem, I hope you can help me. The main goal is to control the daemon from the RPi itself with commands I can use in a small script or cron. Thanks.

share|improve this question
    
Can you please make a request in debug mode and show the output: transmission-remote -l --debug –  Jivings Jan 22 '13 at 8:13
1  
shouldn´t it be 127.0.0.1 in the whitelist? –  HectorLector Jan 22 '13 at 13:53
    
Uh. You're right. It works now. But why? Shouldn't localhost be resolved? I didn't think about that IP that much because I was sure about the localhost... Thanks a lot. –  verpfeilt Jan 22 '13 at 22:12

2 Answers 2

You may need to change SSH configuration to enable SFTP.

Look at ssh config file and check that sftp is enabled:

sudo nano /etc/ssh/sshd_config

You should se this line:

Subsystem sftp /usr/lib/openssh/sftp-server

If not, either uncomment it or add it.

share|improve this answer
    
The problem is already solved, see comments of the question. –  verpfeilt Jun 24 '13 at 17:35
    
@chocobai: Yep. Did not saw that –  Tomap Jun 25 '13 at 16:51
up vote 0 down vote accepted

I just wrote 172.0.0.1 instead of 127.0.0.1, also it does not seem to resolve hostnames like "localhost" by default. This is why it did not work.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.