File Chooser not available for selecting Destination folder when adding a torrent in a remote session.

[introspect10n]

What is the issue?

I have transmission installed where the daemon runs as a limited user and I connect to the remote session exposed for all my download + sharing duties. Recently, the ability to use 'file choosers' [file pickers / dialogues] has broken for both choosing 'Destination folder' during adding a new torrent as well as 'Set location' for existing torrents.

I initially thought it was an issue stemming from the transmission-qt client but I compiled a previous version and ran it to the same effect [ie no file chooser]. I then tried the windows client [which I believe is based on the QT build although it doesn't indicate that in Help -> About (neither does the linux client tbh].

Both the server daemon and clients [transmission-qt and windows transmission build] are 4.0.5 builds.

Specifically:

Client: 4.0.5 (a6fe2a6)
Server: 4.0.5 (a6fe2a6)

Note that everything works in the local session [all file choosing behaviour works as expected / as it previously did].

I also looked at the web client via a browser and it exhibited the same behaviour. I do not recall if file selection dialogues were available via the web client or not so this may be 'working as intended behaviour'.

I have tried both GTK file choosers and QT file choosers [via qt5ct and qt6ct] and it affected settings for the local session but not the remote session [ie the correct GTK or QT file choosers worked as expected].

Anyway, I'm not sure what has changed - I did pacman -Syu + manual kernel update + rebooted and I've had this behaviour since.

Permissions haven't changed on folders in anyway.

I think I'll add some screenshots and hope I've been clear enough in describing the problem.

I'm filing this under the transmission-daemon because it seems to affect multiple clients... all running against the same daemon service. I could be totally wrong on this - I believe all the clients are qt-based so perhaps it is a QT specific issue (Assuming the web interface normally lacks file chooser options)?

I tried the GTK client for linux which doesn't have 'change session' option and, as expected, it's local session works fine as well.

A couple of screenshots to visualize the difference.

Which application of Transmission?

transmission-daemon

Which version of Transmission?

4.0.5 (a6fe2a6)

[killemov]

The web-UI does not and never did have an implementation for selecting remote (server side) paths.

[introspect10n]

Thanks for your reply. The webui was the only non-qt interface I had available to check with but I wasn't aware of it's proper behaviour - your confirmation is appreciated :)

I went down the rabbit hole a bit today, so to speak, and discovered this line in OptionsDialog.cc:

ui_.destinationStack->setCurrentWidget(is_local_ ? static_cast<QWidget*>(ui_.destinationButton) : ui_.destinationEdit);

The TL;DR is that there is a check for local session and the destination folder will be presented as a button if "is_local" but as an editable text field otherwise.

This part of the code has been the same since at least 4.0.1 [looking through source code @ https://github.com/transmission/transmission/releases].

I downloaded/compiled/installed/ran 4.0.4 and 4.0.3 and they present the same behaviour as 4.0.5 i.e. File Chooser if local but not remote.

I am annoyed that the functionality I was previously seeing was likely a bug. I don't know because I am having a hard time following what determines 'is_local' - there is session and rpc and I will perhaps follow up with fresh eyes another time.

I would think I'm gaslighting myself except I remember how annoyed I was at first by the Destination folder 'button' because I couldn't copy/paste a folder into the field like I used to when downloading many things to the same folder sequentially.

I then grew to love it because when I was putting sequential downloads in different folders, a couple of clicks beat a bunch of typing :D

Anyway - I should close this because it now seems to be acting 'as intended' - from what I can see in the code.

Also - I'm convinced I would want to submit this as a bug [or request as a feature] against transmission-qt and not transmission-daemon since the code determining 'File chooser' mode is under qt. Perhaps the is_local functionality is determined by the daemon, though, I honestly don't know - yet.

I can also go through old filesystem snapshots and see if/when I actually had the functionality if I have some time in the near future.

Perhaps, if I'm adventurous, I can even write something like:

ui_.destinationStack->setCurrentWidget(static_cast<QWidget*>(ui_.destinationButton))

and recompile/install to see if I get the behaviour I desire out of it - lol :P

I am technically running it local - just that the daemon is running as another user... but it's on the local filesystem...

[mikedld]

Determining the value of is_local_ is based on daemon (or another session "server") creating and locking a file in /tmp (with name containing current session identifier, shared with the client over IPC), and Qt client (or another session "client") checking if that file exists and can or cannot be locked. If e.g. the client cannot find the file for some reason, it'll decide that the session is truly remote even when running on the same computer as the server.

One cause for what you're seeing could be your daemon configuration; e.g. if it's running as a systemd service, and PrivateTmp is enabled in the service configuration, then daemon will be creating its file in a private directory that's not /tmp and that Qt client knows nothing about. Looking through our code, I regret to say this but I guess I should've found time to push back some more on #1452 which indeed has added PrivateTmp to the systemd service file that's in our repo and that package maintainers could supposedly use as is; that session lock file is basically the only file that is created in /tmp and there was no good reason in making temp directory private as it makes the local session checking functionality defunct :(

TL;DR Remove PrivateTmp from your systemd service configuration file. We should probably think of the ways to fix this one way or another, so I'm going to re-open this issue.

[killemov]

There now appears to be a major disconnect between the title of this issue and what is discussed within. @mikedld
Yes, this configuration issue should be fixed. But what about adding remote path access to the RPC-spec?

[mikedld]

I don't think adding remote FS operations (even if just read-only traversal) to RPC is a good idea, we're not a file manager and there're security implications in letting people see what other files (except torrents within the session) the [truly] remote system has.

[killemov]

@introspect10n So maybe change the title of this issue to match the content?

See #6044 for reference.

@mikedld I suggest to start with a configurable selection of root paths you cannot escape and only show folders.

[introspect10n]

Hi again :)

Apologies - I was monitoring this thread on and off this week + had even started a reply but life happens /sigh...

First, @mikedld, thank you for your excellent explanation: you hit the nail on the head. PrivateTmp was set in the configuration file - I set to false and restarted [in case true becomes the default] and my problems were solved.

It's funny that #1452 was committed almost 2 years ago and I happened to have just seen the behaviour recently... It's because I usually overwrite the package managers /lib/systemd/system/transmission-daemon.service file with my customized one [vs editing everytime I update transmisssion. This time I noticed that there was a transmission.service as well as a transmission-daemon.service - apparently Arch's package has renamed the service for some reason...?

When noticing the 2 different service files - I realized that the transmission.service one had far more entries that were probably important so I figured I would remove my custom one and tweak it instead... thus my having PrivateTmp=true.

Of course in all my testing of previous builds I did after initially reporting on this were using the new transmission.service file [I just changed /usr/bin/ to /usr/local/bin and kept make-installing systemctl start transmission.service and noticing nothing changing all the way back to 4.0.1... even though I could swear the File Chooser worked on old versions /sigh...

At least I'm not crazy [in this instance] - lol :P

Also - I guess the bug would technically be filed against transmission-daemon after all - even though it's an interaction between the daemon and the client - changing the transmission-daemon.service file is actually what fixes it.

Second, @killemov I'm not sure what you'd like the new bug title to be - feel free to make a suggestion. I feel that my title is reflective of the problem I had and @mikedld gave the required information + short term fix while acknowledging that the issue may need to be looked at further.

I love the idea of remote path browsing, having multiple paths saved, etc ala importing files manually in Sonarr [for example]. Although @mikedld mentions reluctance to become a file manager or deal with the security implications of adding the kind of functionality you mention in #6044 for example. While said functionality would definitely solve my issues - that is a feature add and not a bug, IMHO.

My suggestion for dealing with this issue [PrivateTmp] is that the "extra variables" should not be set in a systemd service file for a couple of reasons:

Not all linux distro's (only 99.9% of them) use systemd. Anything variable-related that affect the operation of the daemon should be exposed through settings - if not the interface itself than the remotes' setting.json at a minimum. For example, putting a setting like "Allow File Chooser compatibility for local login to remote session [with a help file link or tooltip on mouseover and or a better description]. It could look something like:

This checkbox could toggle the PrivateTmp setting which could be saved in (and read from on startup/change) settings.json instead of a systemd services file.

That would fully encapsulate a fix for the particular problem I opened the thread with.

Thoughts?

[introspect10n]

I'm not sure if I should open a new thread but this is related enough I will post here for now:

There is just one problem with my proposed solution: the "Remote" tab isn't showing me the "Remote" settings of the remote service [ie transmission-daemon] - it's showing me the "Remote" settings of the local client [ie transmission-qt]. My "Remote" is enabled, set up on 9090 with a username and password - I'm 99% certain that I did this in the exact page I've screenshotted (from the transmission-qt client) - especially since there is no way I encoded the password in the remote settings.json file myself... so I must be going crazy again, perhaps? Was this functionality previously exposed? If so - when/why did that change? Am I experiencing a bug? Or have I finally lost my last marble?