GNOME Bugzilla – Bug 167082
Two authentication dialogs thrown while accessing a samba share
Last modified: 2008-09-06 19:08:24 UTC
Please describe the problem: While accessing a samba share, two authentication dialogs are shown to the user. Steps to reproduce: 1. Launch nautilus and access a samba server by entering smb://server-name in the location bar 2. It shows some samba shares 3. Click on any share which requires authentication. You will observe that two authentication dialogs are shown. Actual results: Expected results: Does this happen every time? Yes Other information: The problem is seen after the smb-method is re-written.
Does the server in this case list it's shares without password access? So the first password that is needed is for the share. Is that correct?
Yes. Thats correct. My test Server does not require authentication. Shares require it. Also, if I try to access the same share in a single request (smb://server/share) instead of accessing server and then share, I don't see the problem.
Created attachment 37554 [details] [review] Possible fix for the problem.
Could you post a debug log? It means recompiling gnome-vfs from source. Here's some pointers in case you are willing to help. - Before rebuilding gnome-vfs add the following lines to the top of modules/smb-method.c: #define DEBUG_SMB_ENABLE #define DEBUG_SMB_LOCKS - Now configure, make and install (of course, include options specific to your system). - Next run the following commands to get gnome-vfs-daemon running in a terminal: $ gnome-session-remove nautilus $ killall nautilus $ killall gnome-vfs-daemon; /usr/libexec/gnome-vfs-daemon - If the last command returns you to a prompt, try it again. Or close all apps that could be using gnome-vfs. - Start nautilus elsewhere. - You should see lots of nice insightful debug output, which when attached to this bug should help me solve the problem. Thanks
Nielsen, Sorry to come back late on this. I was travelling. When I saw the problem, I was working on a different network where the samba server does not need authentication but shares require. But I am not seeing the problem in the network which I am working on now. I will check again and try to have a setup similar to the one, where the problem was reported. And then I will give the debugging information.
Seeing the two authentication dialogs problem in a similar scenario now. Details are below: Setup: Using samba-3.0.9 with smb-method.c from community HEAD. Accessing samba servers which are part of Windows AD domain. When loging into server, user has to authenticate. And shares need not be authenticated (after user caching changes to smb method) How to simulate: a) Logged into any of mentioned servers after providing username, domain and password. Some shares under the server are shown. Say there are at least two shares. b) Open the first share. It will open and shows files/folders under it. c) Browse back to the shares location and try to open the second share under the server. BUG: User will be thrown two authentication dialogs. I will attach debug output, with comments on what could be the root cause.
Created attachment 45248 [details] Debug output when two authentication dialogs are shown
Alex, this seems to be a nautilus issue. Or do the individual gnome-vfs modules have to protect against concurrent authentication?
Narayana, Alex, I didn't see the debug output with the comments earlier. I'll definitely look into this further. Thanks.
I have debugged it further. The issue is here: a) When the server is authenticated, the user credentials are cached in user_cache. And when first share is accessed, the user details are obtained by calling lookup_user_cache(). If they are found in user cache, the corresponding server is looked up in server cache in initial_authentication(). If its also found in cache, the password is set to null string. b) When fist share is opened finally, its details are saved again with/without share in update_user_cache(). But since the password is already set to null string, server with/without share are cached, with null string password. [auth] Saved in cache: m3-lalith1/lalith = cool:wipro@ [auth] Saved in cache: m3-lalith1/ = cool:wipro@ c) When second share is accessed, looking for user details in cache only gives username and domain would be found. Hence it will ask for authentication again. Will submit a patch to take care of the issues.
Created attachment 45278 [details] [review] proposed patch
Yes, change in initial_authentication looks good. That empty password thing is some stuff inherited from the old smb authentication. I have a question about the changes to update_user_cache. What if the user does infact need a new password set. How is that handled?
Whoops (bad click), reassigning to me.
>I have a question about the changes to update_user_cache. What if the user does >infact need a new password set. How is that handled? I was under the impression that user cache is anyway getting reaped every 30 minutes, so, lets not update it again. But, its possible that user can change the password within these 30 minutes and the we won't be getting the new password. So changes to update_user_cache() are not necessary. Please commit changes to initial_authentication() alone.
Will do. Just a double check... Do the changes in initial_authentication fix the 'Two authentication dialogs' problem?
Yes, they fix the problem.
Checked patch in. Thanks.
Created attachment 45949 [details] [review] Only parts of previous patches applied Looks like only some of the patches are applied to head, this is as of today. Here is a corrected patch...
If you create a desktop link to smb://server/share, and then open it, you still get two authentication dialogs pop up. This is with gnome-vfs-2.10.1, with the patches applied.
Is it Unix based or Windows based samba server ? I used to see this problem while accessing a share from a Unix based samba server. I don't have that setup anymore, so, could not debug much.
Yes, it's samba server running on a debian machine.
Is it possible for you to get debug output smb method. Please look at earlier comments, for help to get debug output.
I'am to see the problem with both unix and windows shares, re-opening.
When user accesses unix server shares, server is not authenticated, but when the user accesses its shared folders, then user is prompted for authentication. But in case of windows server shares, first server is authenticated. And later user is allowed to access its shared folders. Looking into unix share, The cause is something like, If user tries to access the share by providing full uri, i.e 'smb://server/share', then only one authentication dialog pops up. But on accessing shares from server locations, i.e log into 'smb://server' (no authentication is asked), then you access the share folders of this location (ex: smb://server/share), you will be asked for authentication, here two authentication dialog pops up. This is because, Initially server is not authenticated, and cache will have null values for server credentials. That means its trying to authenticate both server and share, hence two authentcation dialogs. This problem can also be seen on windows network, reduce smb session timeout to 2 mins and compile the code. Later log on to any windows server share M/c, then wait till timeout, later try accessing shared folders, here two authentication dialog pops up. Incase of two auth dialog, nautilus creates two threads for auth. Hence the problem.
Did some analysis which could help understading the root cause and to help arrive at some solution. Attached debug file has the same information.
Created attachment 46635 [details] Debug info which could help in understanding the problem of two auth dialogs
Updating bug info. Thanks for all your efforts! Do we all agree that the right solution is to use the existing dialog for all pending operations, no matter whether they are async or sync? The user might want to use different users for both accesses, but then again he probably can't figure out the mapping between dialogs and operations.
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of these notification emails all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html