On Fri, Jan 16, 2026 at 04:50:43PM +0100, Manuel Giraud wrote: > As you said, it is fixed now. But just to be more precise, I'm using > the transmission_daemon service (via rcctl enable transmission_daemon && > rcctl start transmission_daemon) and it is working inside > /var/transmission by default. > > > You could always delete or move your .json file out-of-the-way, which will > > recreate a default settings.json, then provision with cli options or > > with a connected -qt client, rather than a text editor. If cli or -qt > > provisioning > > works correctly, you'll know your manual edit was the root cause. If it > > won't > > work properly using the application tools, then you have found a bug, and > > you could always open a new issue with the upstream project. They would > > need > > your complete settings.json file, of course. > > Well I don't really know because I did not do any manual editing (or > modify any options) before seeing this misbehavior. It seems to me that > upgrading from "transmission-4.1.0beta4" to "transmission-4.1.0beta5", > the transmission-daemon starts filling my /var partition while it was > happily writing elsewhere before that. > -- > Manuel Giraud
All of the settings files and directories are created by the application with defaults, if they don't already exist in the user's $HOME/.config/transmission-daemon/ directory. The _transmission userid, used with the transmission_daemon control script, is just another user, with a $HOME of /var/transmission, so it's provisioning directory is /var/transmission/.config/transmission-daemon/. As you stated, there was an ongoing resume, so the cause might have been something in the resume/ subdirectory, or, it might have been something in the project's snake_case transition from b4 to b5.
