GNOME Bugzilla – Bug 685290
Storing passwords for certain locations doesn't work
Last modified: 2021-06-18 15:32:38 UTC
Not sure if this is nautilus' or gnome-keyring issue. Despite selecting 'remember password until you logout' or 'remember forever', some of my sftp:// bookmarks always prompt me for a password. The culprit might lie in that my local user does not match the remote one (jimmac vs jsteiner), but that's just a speculation. Maybe a similar authorization issue as https://bugzilla.gnome.org/show_bug.cgi?id=685287
I'm experiencing the same issue in Nautilus 3.6.2.
I did a git bisect and traced the issue to this commit: ed9057711896dd71a6e1524b9fcf963b9adb24c0 is the first bad commit commit ed9057711896dd71a6e1524b9fcf963b9adb24c0 Author: William Jon McCann <jmccann@redhat.com> Date: Fri Apr 27 12:57:14 2012 -0400 Use new GTK bookmarks location If it doesn't exist fallback to reading from the old location but always write to the new location. https://bugzilla.gnome.org/show_bug.cgi?id=674986 However I'm not sure how to fix the problem.
(In reply to comment #0) > The culprit might lie in that my > local user does not match the remote one (jimmac vs jsteiner), but that's just > a speculation. Good speculation, that's the case for me as well.
The username isn't making it into the bookmark when at the connect to server dialog you enter a URI of the form sftp://server.com/folder. When you do this, GtkMountOperation prompts for username/password and the password is properly stored in the keyring associated with a URI of the form sftp://username@server.com/folder, so there's nothing wrong with the keyring integration. The problem is the username never becomes part of the bookmark, so the keyring has a password for location sftp://username@server.com/folder but the bookmark is for location sftp://server.com/folder. If at the connect to server dialog you enter a URI of the form sftp://username@server.com/folder then gnome-shell will prompt you for only your password, and your username will be part of the bookmarked location so everything will just work. There's a really simple workaround for existing bookmarks: click on Bookmarks from Nautilus's application menu and just add your username to the URI. This works for Bug #685287 as well. I have not figured out how to fix this, but we clearly need to insert the username into the bookmark's location field. Also as a side note, this all seems unrelated to the commit I blamed... maybe I wasn't careful enough and bookmarks from the old location affected my results, not really sure what went wrong there.
Hmm, without taking a look at the code it seems that if Nautilus is not given a username it simply uses the local user when searching for a matching key. I guess to fix this Nautilus needs to fallback to search for any matching URI in the key chain if the local user has no matches (no idea if this is possible I'm just speculating). I will take a look at the code for this when I get a chance. Would be great to fix this its one of the few bugs that I hit regularly that makes Linux look sloppy in comparison to Windows and it drives my wife mad as it happens every time we connect to our NAS
So a quick test from the command line to my NAS that has the the username/password saved. Test 1: ------- gvfs-mount afp://DiskStation.local/ Result: ------- Asks for user name and password Test 2: ------- gvfs-mount afp://admin@DiskStation.local/ Result: ------- Connects successfully. No password prompt. So maybe this is a bug that needs to be fixed in gvfs rather than Nautilus
Also something to note. Once the location is mounted if you try 'gvfs-mount afp://DiskStation.local/' again you are prompted for a username and password rather than getting the message 'Error mounting location: Location is already mounted'
(In reply to comment #5) > Hmm, without taking a look at the code it seems that if Nautilus is not given a > username it simply uses the local user when searching for a matching key. > > I guess to fix this Nautilus needs to fallback to search for any matching URI > in the key chain if the local user has no matches (no idea if this is possible > I'm just speculating). I will take a look at the code for this when I get a > chance. Would be great to fix this its one of the few bugs that I hit regularly > that makes Linux look sloppy in comparison to Windows and it drives my wife mad > as it happens every time we connect to our NAS Don't forget: There's a really simple workaround for existing bookmarks: click on Bookmarks from Nautilus's application menu and just add your username to the URI. As far as actually fixing it... the interesting files in nautilus are nautilus-application.c and nautilus-connect-server-dialog.c. (nautilus-connect-server.c is a distraction - that's a command-line program for launching the connect server dialog outside of nautilus.) Anyway I think this is probably a Nautilus bug rather than anything wrong in gvfs: in on_connect_server_response (nautilus-application.c) there is a call to nautilus_window_slot_open_location_full which takes the server location as you type it. If you give it your username in the address, e.g. michael@server.com then the username gets passed to a GtkMountOperation (and from there through a surprising number of layers of library) and everything works; if you leave off the username then GtkMountOperation will prompt you for it, but Nautilus doesn't ever see that - it only knows that GtkMountOperation has mounted the original location, and creates a bookmark for the original location (which did not have the username!). The password is stored properly in all cases. There used to be (in 3.4.x) a lot of code for handling displaying server locations differently than local file locations; perhaps it was all redundant code, but maybe it was there for this reason. I could be mistaken, but I think we either need to add a way to get the username out of a GtkMountOperation, or else restore the old code.
(In reply to comment #8) > As far as actually fixing it... the interesting files in nautilus are > nautilus-application.c and nautilus-connect-server-dialog.c. > (nautilus-connect-server.c is a distraction - that's a command-line program for > launching the connect server dialog outside of nautilus.) Thanks Michael this is a great place to start. > Anyway I think this > is probably a Nautilus bug rather than anything wrong in gvfs. I disagree with you here. You are only talking about getting Nautilus to work with bookmarks while this would be an improvement it wont fix connecting to non bookmarked locations. Such as sftp locations entered manually or Network locations clicked on via the browse network shortcut. If gvfs was updated to use a stored user/password without being explicitly given a username all on the scenarios would be solved. Its possible we would need to present a dialog to choose from multiple stored users and have the option to add/use a new one also.
*** Bug 730275 has been marked as a duplicate of this bug. ***
*** Bug 736823 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.