! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
[thunar] Thunar doesn't remember FTP passwords ("forever").
Status:
RESOLVED: FIXED
Product:
Thunar
Component:
Documentation

Comments

Description René Herman 2012-12-13 01:26:16 CET
Hi guys,

having been mightily impressed by the speed with which the last such bug-relay was resolved, here's another relay from the arch bugzilla:

=== https://bugs.archlinux.org/task/33071

Thunar allows FTP logins, by Go | Open Location (Ctrl-L) and will put up a dialog asking to "Connect anonymously" or "Connect as user" with Username/Password fields, and providing the options to "Forget password immediately", "Remember until you logout" and "Remember forever".

It also allows FTP bookmarks since a few versions (drag the entry of the logged-in site from the NETWORK section in the bookmarks-sidebar to the PLACES section) and certainly for those, the option to have the password stored "forever" would be quite welcome -- but it doesn't work for me.

Thunar uses GVFS to open FTP sites and I expect that it would be the gvfsd-metadata daemon that is responsible for storing/retrieving the password, but that daemon does not seems to be launched on my system. It is installed (as part of the gvfs package) and I do have a .local/share/gvfs-metadata folder with some gunk in it, which seems to imply that SOME things manage to launch it...

I expect that this will be an Arch specific problem? (if it wouldn't work generally, the Thunar developers would've supposedly noticed: the remote-bookmarks stuff isn't very old yet).

I'll go ask there as well, even if only to have confirmed that this is Arch specific, and hopefully obtain some pointers as to what is needed to have it work -- but if in the meantime someone could confirm that it's not just me, that would be useful. It's a difficult issue to google for since every single one of these bleeding fora seems to have a "lost your password?" button somewhere on the page, making one drown in irrelevant hits...

Latest Thunar (1.6.1-1).

===

Many thanks in advance for any pointers.

Kind regards,
Rene
Comment 1 Nick Schermer editbugs 2012-12-13 13:41:04 CET
Afaik this is a responsibility of gvfs (ie we use the same code to setup the connection as nautilus). Passwords are stored in the gnome-keyring, metadata only holds stuff like emblems.
Comment 2 René Herman 2012-12-13 19:29:07 CET
Yes, thank you. I did needgnome-keyring (itself); there's a comment describing it back at the Arch report now:

https://bugs.archlinux.org/task/33071

However, this would seem to say that currently gnome-keyring is an (in arch) implicit dependency of thunar and I'm wondering what the best way would be not have that.

I did already have libgnome-keyring installed, pulled in as a dependency of evince it seems, just not the actual gnome-keyring package. I am completely unaware of how this stuff is intended to work, but -- would linking thunar against libgnome-keyring be an option that foregos the need for gnome-keyring itself?

Also, and although I expect not (since this stuff seems to happen in the background): would it otherwise be possible to grey-out the option to store passwords forever if they could not be due to missing dependencies? In that case gnome-keyring could be an explicit optional dependency of thunar, which would be fine.
Comment 3 René Herman 2012-12-13 22:38:53 CET
Right...

I'm only finding out after unsuccessfully grepping the Thunar sources, that it's not even Thunar putting up that "remember passwords forever" dialog -- that's GVFS itself also.

Fairly unexpected to me (since I thought of GVFS as underlying infrastructure only) but I take it this means that even if Thunar WANTED to be helpful by pointing out a missing component on my system, it simply couldn't, since it's just not involved by an entire level of abstraction.

If that's right, feel free to close this -- but thanks for the pointer.
Comment 4 Nick Schermer editbugs 2012-12-14 08:33:25 CET
Moving this bug to the docs, it is indeed for users an unexpected requirement, so will write this down at docs.xfce.org
Comment 5 Harald Judt editbugs 2015-04-17 16:19:43 CEST
Closing.
Comment 6 Simon Dedman 2016-02-20 17:21:33 CET
Hi all, apologies for necromancing this thread, but I have a very similar problem & I'm not sure it can be as justifiably punted to the docs.

Xubuntu 15.10 Thunar 1.6.10 trying to access smb shares (synology NAS), same issue: asks for password each time; sometimes asks for keyring before, sometimes after. I have already gnome-keyring installed (ref René's thread) but can't use the 'blank keyring password' (per this thread: http://forum.salixos.org/viewtopic.php?f=16&t=6738&sid=f539fd6af91b2328803ef63ea18b6e77) because I don't have seahorse installed and there's nothing about keys in the menu.

Does anyone else have vanilla xubuntu 15.10 and have this issue? I kinda feel like if this is normal then it's a problem since - irrespective of whether thunar itself should be able to deal with it - it's a bug from the POV of an xubuntu user, right?

Thanks for any thoughts on the matter, esp any tips for solving.
Comment 7 Simon Dedman 2016-02-20 17:28:02 CET
edit: apologies, didn't understand that seahorse is a frontend to gnome-keyring among others. Having installed it now, in the default keyring section I have
admin@nas (smb://admin@nas/)
and
admin@nas.local (smb://admin@nas.local/)

both with same nas username and password. I get prompted for the defaul keyring password (not the same as the nas one), which I enter... my feeling is that gnome-keyring should then release the username/password combo to this gvfs popup?
Comment 8 Simon Dedman 2016-04-27 16:54:20 CEST
In addition, the name of this bug should be changed to reflect that it affects SMB and network browsing folders, as well as ftp. I don't understand why this was closed as it's not resolved: as I understand it, Thunar isn't responsible, however Thunar is where the problem presents itself, and thus for users with Thunar as the default file system (Xubuntu, others?) this will pop up and users will intuitively look here. Additionally, if this doesn't work by default, then I feel it's somewhat the responsibility of the (x)ubuntu/linux community to fix this as it's an unexpected behaviour/bug. Passing the buck may be the technically correct thing to do here, but IMO it helps nobody and reduces the chance that the problem will be resolved.

Bug #9631

Reported by:
René Herman
Reported on: 2012-12-13
Last modified on: 2016-04-27

People

Assignee:
Jannis Pohlmann
CC List:
5 users

Version

Attachments

Additional information