![]() I'm working tonight but later or tomorrow I'll try to fully get it working and integrated with Sonarr/Radarr, and then work on importing my few thousand torrents to seed again. It is not currently supported in FUSE w/ direct_io enabled.īut not immediately obvious that the filesystem was the issue.ītw - don't know if you've spotted that has released some nice tools a while back for MergerFS. Do not use direct_io if you expect applications (such as rtorrent) to mmap files.I've never used direct_io for mergerFS so never had that problem. funny how you end up looking any and everywhere Removing that argument from my pool has allowed rtorrent to work as expected, finally! Thank you for all your time, and apologies to the original OP of this thread for completely taking it over. I've tried the resetperms plugin on my storage pool but this doesn't seem to fix the problem.įinal edit (?): I think I've found that rtorrent can't write files to mergerfs while using the direct_io option. This is working fine, but once the torrent data is moved, the torrent shows the new, correct save path, but I can not verify local data and begin seeding. Could this be causing the issue? Can rtorrent/rutorrent not save to a mergerfs pool? Is there anything different I need to do with my rtorrent.rc file?Įdit again: I've temporarily set up rutorrent saving to a non-pool directory and moving completed torrents into the pool. What I have been trying to establish is mapping /downloads to my mergerfs pool. New information: when mapping /downloads to the same directory as /config (on my system drive), the downloading works perfectly fine. In fact, no other Docker containers' mapped volumes are owned by the docker user, they are ALL owned by root/users except the rutorrent container. The download directories there remain owned by root/users. I think this is the expected behavior, right? However, this doesn't happen with other containers that download data, like NZBGet. The owner/group for the /downloads directory is my docker user. ![]() I don't know if that is related, because I have the folders set that everybody can read/write/execute (at least until I figure out what's going on). Each time, I use the OMV UI to view the folders' ACL settings, and the owner has switched back to the user whose UID and GID was mapped. ![]() It seems that the container is resetting the permissions every time it is launched. Schedule = low_diskspace,5,60,close_low_diskspace=100MĮncryption = allow_incoming,try_outgoing,enable_retry # schedule = watch_directory_1,5,5,"load.start=/downloads/watched/*.torrent" Log.open_file = "rtorrent", /config/log/rtorrent/rtorrent.log Schedule = socket_chgrp,0,0,"execute=chgrp,abc,/run/php/.rtorrent.sock" Schedule = socket_chmod,0,0,"execute=chmod,0660,/run/php/.rtorrent.sock" Code execute = Įxecute.nothrow = rm,/run/php/.rtorrent.sock
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |