All torrents "Queued for verification" after restarting transmission-daemon

Ask for help and report issues not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
BobTheBob
Posts: 3
Joined: Fri Jun 05, 2020 9:46 pm

All torrents "Queued for verification" after restarting transmission-daemon

Post by BobTheBob » Fri Jun 05, 2020 9:54 pm

Hello,

OS: Ubuntu 20.04
Transmission-daemon 2.94 as a systemd service

I migrated my download and config directories from one machine to another, also upgrading transmission to a more recent version (2.94), and made sure the user under which the daemon runs has read/write access to the config and download directories. However, 2 strange things happened:

1) all my torrents (in configdir/torrents) disapeared by themselves. I manually put them back. The "resume" files were still there. When I re-populate the "torrents" directory, the torrents show up again in the web interface and the download locations are correctly remembered.
2) the real problem is that every time I restart the daemon, all the torrents begin to be verified. After verification, they are all green and "seeding", but if I restart the daemon, all torrents are being verified again.

I'm pretty sure I did something wrong in migrating my transmission config. Does this problem sound familiar to someone?

Thanks

BobTheBob
Posts: 3
Joined: Fri Jun 05, 2020 9:46 pm

Re: All torrents "Queued for verification" after restarting transmission-daemon

Post by BobTheBob » Sat Jun 06, 2020 5:22 pm

Think I solved it: "group" and "other" had read access for the torrents I added back to the "torrents" config dir. Removed these permissions and it seems fixed now.

BobTheBob
Posts: 3
Joined: Fri Jun 05, 2020 9:46 pm

Re: All torrents "Queued for verification" after restarting transmission-daemon

Post by BobTheBob » Mon Jun 08, 2020 8:38 am

Was still having issues, manually added torrents (to the "torrents" config dir) could not be removed via the remote interface. They dissappeared from the list, but reappeared after application restart. Had the same behavior with the latest 3.0 from git.

Gave up and started with a fresh, empty config dir. Everything is OK now.

Post Reply