You are not logged in.
Pages: 1
Topic closed
If i use the package as it is installed with default settings it will work perfectly. When i change the download directory to /home/myuser/downloads/transmission it will throw 'permission denied' errors all over my journal. I want to change the standard download directory because it is located in /var/lib/transmission, which is on my root partitition, which is small.
Now every post/thread/blog on the internet sugests that adding 'myuser' to the transmission group and changing the permissions on the custom download folder so that every user on the transmission group can write to it will do the trick. But even configured in that way it will not work.
I suspect this behaviour is due to the fact that the home directory of myuser has 700 permissions, and is owned by myuser:users.
Is there a clean and neat way to let tranmission-cli download to my home dir, without sacrificing security, i.e. letting the daemon run as user: transmission without a password, belonging to the group transmission, but storing downloads in the home dir of myuser.
Offline
Why not let it run as your user?
You can set the user it runs as in its service file.
Offline
also the cli client does not upload the other torrents already downloaded.
Offline
Can transmission write to your downloads directory without permission? no. Hou can use ACLs to grant transmission rw access to your downloads folder and the list permission on your home directory.
Offline
Why not let it run as your user?
You can set the user it runs as in its service file.
I could do so, but everywhere I read that it is not OK to run a daemon as the user who also has admin rights. Things like tvheadend and mariadb also run as seperate users on my server.
also the cli client does not upload the other torrents already downloaded
I am not sure I understand what you are saying. But I removed the torrent and stopped the daemon before every test or changing stuff in the settings.json file.
Can transmission write to your downloads directory without permission? no. Hou can use ACLs to grant transmission rw access to your downloads folder and the list permission on your home directory.
ACL was one of the things I found when googling around but i haven't tried it yet because I wanted to try other things first.
I now have moved the home dir of the transmission user with the usermod command to /home/transmission and gave that dir 750 permissions so I can access it with my normal user. This works, obviously, but still there is the question of what is the 'correct' way of doing things with daemons and why is the default home directory of a program most commonly used to download large files located in /var/lib/* ?
Offline
Offline
I use transmission-daemon on my server and transmission-remote-cli on my laptop to connect to it. The transmission-daemon runs as my user, and I believe that this is the correct way of doing it. Otherwise, you have to have a special area for the transmission user to download to. /var is probably not to apprpriate place for this, and if you want it to download to your home folder, then you have to give transmission write access to wherever it is you want it to go.
I guess you could run it as transmission, then use the /home/transmission as a download directory while retaining /var/lib as its proper $HOME.
Honestly, I would just run it as my own user (wait.... I do). Just copy the transmission service file to the proper /etc directory and change User=transmission to the necessary user. Or better, rename it to transmission@.service and then make it User=%I. Then you can start transmission@<you>.service instead.
Offline
I see no problem in running transmission as a user, if it indeed serves only your user. You'd run irssi or somesuch (in screen/tmux) on your server as a user too.
Last edited by lucke (2013-04-18 06:56:40)
Offline
When I first switched from using transmission-gtk to transmission-cli and transmission-remote-gtk, (using systemctl to start the daemon) I had the same problems with file ownership. Even though I had changed the config file in /etc, the transmission user still owned everything and caused lots of grief.
Since I already had all my settings in my home directory and I am the only user on this machine, I found that the easiest way to fix it was to start it myself on the rare times that I reboot. So I made an alias in my ~/.bashrc:
alias st="transmission-daemon -g /home/{myuser}/.config/transmission --log-error"Now I own everything and all I have to do is remember to run "st" after a restart, though there is probably a way to automate this.
Offline
<snip>
Now I own everything and all I have to do is remember to run "st" after a restart, though there is probably a way to automate this.
Dude, just modify the provided service file to fit your needs. Copy /lib/systemd/system/transmission.service to /etc/systemd/system/transmission@.service, and then change "User=transmission" to "User=%I". Then enable it (systemctl enable transmission@ronmon). Done
Offline
Maybe I'll give that a try. I know I did the first part, which didn't work how I wanted it to. I did not do the "transmission@ronmon" part, so I guess that's the trick I missed.
Thanks.
Edit: Did not work. Read the wiki, man pages and more trying to figure out the various failure messages. Won't start either manually or on reboot.
Apr 18 15:22:06 maxx systemd[1]: Starting Transmission Bit Torrent Daemon...
Apr 18 15:22:06 maxx systemd[1]: transmission@ronmon.service: control process exited, code=exited status=217
Apr 18 15:22:06 maxx systemd[1]: Failed to start Transmission Bit Torrent Daemon.
Apr 18 15:22:06 maxx systemd[1]: Unit transmission@ronmon.service entered failed state
Failed to issue method call: Unit name transmission@.service is not valid.
Warning: Unit file of transmission@ronmon.service changed on disk, 'systemctl --system daemon-reload' recommended.
Process: 1486 ExecStart=/usr/bin/transmission-daemon --pid-file /run/transmission/transmission.pid (code=exited, status=217/USER)There are more, but you get the idea. I ran 'systemctl status' and 'journalctl -xn'. Tired of messing with it. My way may not be elegant, but it works for me.
Re-edit: Did some more digging and found the problem.
Last edited by ronmon (2013-04-19 00:09:49)
Offline
Re-edit: Did some more digging and found the problem.
... and it was...
These forums are not here only to help you, but also for future seekers of solutions.
I forgot to mention that if you are having the pid file written to /run/transmission/transmission.pid, you need to also change the /usr/lib/tmpfiles.d/transmission.conf so that it reflects your uid. If you don't it won't be able to write the PID file, and will fail.
It is also telling you that you need to do a daemon-reload, as the service configuration that is in memory is not the same as what is on disk. Do you just not read those messages or what?
Offline
It couldn't write the pid file. That's what my digging revealed as well as the fix.
Offline
Just out of curiosity, did you simply edit the file in /usr/lib/tmpfiles.d? Because it works like systemd service files and the conf file should be copied to /etc/tmpfiles.d then modified there. Otherwise an update might very well overwrite the changes you have made.
Offline
I chown'd /run/transmission and edited /usr/lib/tmpfiles.d/transmission.conf , /etc/tmpfiles.d was empty, so I have now copied it there too.
It would be nice if the powers that be would make up their fricking minds and stick with a plan. Since 1997 there have been several init systems and 4 or 5 ways of populating /dev. Every time they change it I have to learn everything over and it's like being a n00b all over again. Sometimes I think these guys sit around in their mom's basements dream of ways to tick me off.
Offline
Yeah, that kind of crap has no place here.
I'm happy to do my best to lend a hand and help you out with issues you may have. But reading your whining about changing init systems is not what I come here for. Get a blog for that shit.
Offline
lol
Offline
I think this thread has run it's course.
Ronmon: please read our policy
Edit: Leaving the thread in place as it does have technical merit.
Last edited by ewaller (2013-04-19 17:18:56)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Pages: 1
Topic closed