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.
No comments:
Post a Comment