-> gvfs

Credentials are handled by gvfs and not by Nautilus directly. What kind of server are you trying to connect to (SMB, ssh, WebDAV, ...)?

SSH in my cases.

I can't reproduce it on my Fedora 20. Are you able to find your credential for your ssh server using seahorse application? Does it work for you for different protocol?

I run Fedora 20 + Gnome 3.12.

Yes, I can find the credential in SeaHorse, but Nautilus still asks for it.

Unfortunately, I don't have any other protocol I can test, Windows could be, but I use an Enterprise Account (Kerberos) to connect my Windows shares.

Thanks for the info. It could be something similar to Bug 682801, or Bug 600678. What is a format of the server uri? Is it same uri as you can find in the seahorse application? Can you reproduce it on sftp://localhost/?

OMG, 5 years old bugs still not fixed!!

Nautilus: sftp://<ip>/home/<login>
SeaHorse: sftp://<login>@<ip>

(In reply to comment #6)
> Nautilus: sftp://<ip>/home/<login>
> SeaHorse: sftp://<login>@<ip>

Looks correct, so saving credentials works correctly...

I've just made additional testing.

It works with ftp urls, not with sftp ones.

Thanks, so getting credentials from the keyring also works. So the problem is probably in the sftp backend. Are you using any special server configuration? 

Please try to login to your server using ssh, do you see something else?
$ ssh localhost
oholy19@localhost's password: 
Last login: Thu Sep 25 18:05:01 2014 from localhost.localdomain
$

Does it work for you from another distribution or live system? If not could you provide temporary testing access to your server?

From a terminal, I can ssh any server I want. Mostly external hosted server running Ubuntu Server 10.04, internal servers running Ubuntu Server 14.04, even my Nokia N9.

I've NEVER faced any issue to use ssh from the terminal, nor from Nautilus either, except this credentials issue.

I haven't any doubts about ssh works correctly for you, but I'd like to now, whether the output looks exactly (if you replace username and domain) like the output in the comment 9. Sftp backend uses ssh and parses its output, so there might by problem...

Also you didn't answer my last question from Comment 5, can you reproduce it on sftp://localhost/? or with another sftp shares?

We need more information to be able to fix the problem...

I can reproduce it on the 2 computers I use on a daily basis, my personal one and my professional one. Both run Fedora 20 + Gnome 3.12.

"ssh localhost" output:
------------------------------------------------------------
[romu@xps ~]$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
romu@localhost's password: 
Last login: Thu Sep 11 15:43:30 2014
------------------------------------------------------------

Of course, the key fingerprint is not this one.

ssh user@192.168.0.7 (my Nokia N9)
------------------------------------------------------------
[romu@xps ~]$ ssh user@192.168.0.7
user@192.168.0.7's password: 


BusyBox v1.20.0.git (MeeGo 3:1.20-0.2+0m8) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ 
------------------------------------------------------------


I can NOT reproduce it by mounting "sftp://localhost/" from Nautilus. In this case, once the credentials have been registered, I don't need to enter them anymore.

(In reply to comment #12)
> I can reproduce it on the 2 computers I use on a daily basis, my personal one
> and my professional one. Both run Fedora 20 + Gnome 3.12.
> 
> "ssh localhost" output:
> ------------------------------------------------------------
> [romu@xps ~]$ ssh localhost
> The authenticity of host 'localhost (127.0.0.1)' can't be established.
> ECDSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
> romu@localhost's password: 
> Last login: Thu Sep 11 15:43:30 2014
> ------------------------------------------------------------

I suppose this works for you from the nautilus if you wrote you can't reproduce it with localhost

> ssh user@192.168.0.7 (my Nokia N9)
> ------------------------------------------------------------
> [romu@xps ~]$ ssh user@192.168.0.7
> user@192.168.0.7's password: 
> 
> 
> BusyBox v1.20.0.git (MeeGo 3:1.20-0.2+0m8) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
> 
> ~ $ 
> ------------------------------------------------------------

and this doesn't work for you, right?

So at least the second output looks all right. Couldn't you provide temporary access for testing to one from the problematic servers?

> I suppose this works for you from the nautilus if you wrote you can't reproduce
> it with localhost

Right.

> > ssh user@192.168.0.7 (my Nokia N9)
> > ------------------------------------------------------------
> > [romu@xps ~]$ ssh user@192.168.0.7
> > user@192.168.0.7's password: 
> > 
> > 
> > BusyBox v1.20.0.git (MeeGo 3:1.20-0.2+0m8) built-in shell (ash)
> > Enter 'help' for a list of built-in commands.
> > 
> > ~ $ 
> > ------------------------------------------------------------
> 
> and this doesn't work for you, right?

Right

> So at least the second output looks all right. Couldn't you provide temporary
> access for testing to one from the problematic servers?

That's feasible, but not simple. I think the easiest way would be first to exchange some emails address, chat contact would be even better to be able to discuss in real time. The, to decide about some testing hours to be able to give you some guest access to my networks.

The reporter was so kind and give me access to your server. Unfortunately I can't reproduce it with the same version of Nautilus and gvfs when connecting to his server. 

However we have found that gvfs-mount sftp://user@server/ works for him correctly and doesn't ask for the password (even if Nautilus asks for).

He promises he will retest it with fresh Fedora 21 install or from live disk and give us another info...

Hi,
Just took the time to make some testing with my son's laptop which runs Fedora 20 (so Gnome 3.10, not 3.12 like on my own laptop), and ...same.

I've tried to connect my Nokia N9 qith both "Record credentials until logout" and "Forever". Like on other tested laptop, the credentials are well recorded into SeaHorse, and Nautilus still asks for them.

Could it be this issue is Fedora related and not Gnome? As I tested only on Fedora. I can try on some Ubuntu 14.04 laptops at my work, but I don't know if Ubuntu runs a "real" Nautilus or something on their own (NIH syndrom!).

I don't think it is related to Fedora since it works for me (on your servers) and I'm using also Fedora 20. It depends on system configuration probably. You can try it with Ubuntu, but I wonder if it doesn't work there either. I think Ubuntu uses fork of Nautilus, however it uses gvfs anyway.

Ross, don't you have an idea, what's wrong?

(In reply to comment #17)
> Ross, don't you have an idea, what's wrong?

Unfortunately not... this works correctly for me on F20 and F21.

romu, can you you run:
$ dbus-monitor &> ~/log.txt

in a terminal, reproduce the issue, and then upload the log here.  It may give some hints as to what is happening.

Also, do you have any custom options in your ssh client config (or perhaps running some other ssh agent) which may be causing the issue?

Thanks

Created attachment 288726 [details]
Asked log file

Here is the log you asked for Ross. Here is what I did:
1. Connect to my Nokia N9, entering user, password and checking "Remember forever"
2. Disconnect
3. Click "connect" and select again my Nokia N9
4. Wait for the credentials dialog
-> I didn't get connected on this very last step, clicked "cancel".

I've reproduced the issue on a Ubuntu 14.04 laptop.

I've compared your log (which fails) and my log (which succeeds). Credentials are found and sent (it is same for both logs):

method call sender=:1.73 -> dest=:1.8 serial=22 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=GetSecrets
   array [
      object path "/org/freedesktop/secrets/collection/login/26"
   ]
   object path "/org/freedesktop/secrets/session/s4"
method return sender=:1.8 -> dest=:1.73 reply_serial=22
   array [
      dict entry(
         object path "/org/freedesktop/secrets/collection/login/26"
         struct {
            object path "/org/freedesktop/secrets/session/s4"
            array of bytes [
               14 5d c3 cd 41 a7 0f 7f 12 68 2a b5 01 68 87 1f
            ]
            array of bytes [
               d5 12 82 67 3c cc f0 c8 6d a8 96 a0 7b af a0 20
            ]
            string "text/plain"
         }
      )
   ]
...

But something is wrong and there is ask for password (in your case):

"type='signal',sender='org.freedesktop.secrets',interface='org.freedesktop.Secret.Item',path='/org/freedesktop/secrets/collection/login/26'"
method call sender=:1.73 -> dest=:1.70 serial=25 path=/org/gtk/gvfs/mountop/2; interface=org.gtk.vfs.MountOperation; member=AskPassword
   string "Enter password for 10.10.44.163"
...

However it should succeed (in my case) and request for registering mount instead:

method call sender=:1.142 -> dest=:1.3 serial=27 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=RegisterMount
   object path "/org/gtk/vfs/mount/1"
   uint32 11
...

The password is tried probably, but "it doesn't work". The problem might be in the communication with ssh, but I still wonder why gvfs-mount works for you (it uses same api as nautilus)...

Ok thanks Ondrej. Asap, I'll do additional testing. I'll test with my personal computer and my son's one on the server you made the test some days ago and let you know. This will be a way to focus the issue on my phone (server), or on the clients.

Thanks for testing it. Also would be good to test it from fresh installation or live disk to be sure we can except some cases...

Created attachment 289010 [details] [review]
sftp: add more debug prints when logging

So I've prepared debugging prints for sftp when logging. There is scratch build for Fedora 20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7923856

Could you install those packages, execute following command:
pkill -f gvfs; GVFS_DEBUG=1 /usr/libexec/gvfsd --replace >& gvfsd.log
reproduce the problem again and upload the gvfsd.log please?

Ok done on my son's computer. This time, I've tried to connect my brand new Jolla phone which replaces my old Nokia N9. So still Linux based.

I've re-run the steps from my comment 20...and same issue.

The log file is attached.

Created attachment 289065 [details]
Log from the oholy gfvs testing package.

Created attachment 289090 [details] [review]
sftp: Retrieve the username from the secret store

Retrieve the username from the secret store rather than simply using the
default username with the retrieved password.  Without this, the backend
does not correctly recall the login details of a non-default user when
the username is not specified in the URI.

E.g. if my username is "ross" and I stored the login details for "john",
logging in with a URI of sftp://host/path should use john's details
rather than john's password with ross as a username.

If the username is specified directly, e.g. sftp://john@host/path, this
already did work correctly (and should continue to).

The attached patch should fix the problem.

Thanks you both for getting the log and attaching the patch. The patch looks good, however I have made a scratch build again before committing. Romu, could you retest it (hopefully last time) please? 

http://koji.fedoraproject.org/koji/taskinfo?taskID=7929446

Whouuuuuu !! It works ! Tested only on my son's laptop, but I even didn't have to enter my credentials, Gnome retrieved the ones I previously entered for our testing.

Well done guys!

Pushed to master as 9362d9c27354ffdcd8b8100dee3994296e48be38. Thanks for the testing and debug builds!

Comment on attachment 289010 [details] [review]
sftp: add more debug prints when logging

Also pushed to master, it could be useful in the future to solve another login issues...

commit 09e2583e8e3630598208abad620e719df8fac4c3

Could that fix be backported to the 1.20 serie?

Could be, maybe should be, the truth is that the bug is annoying :-)

Comment on attachment 289090 [details] [review]
sftp: Retrieve the username from the secret store

Pushed to gnome-3-12 and gnome-3-10 branches:
commit a76c14f03d6f987cd98fea39db48ef3f5a906dc9
commit a01c028ae02d90c221d0e5420d85b42b3c00b49d

thanks!