Nautilus requests password for unprotected SMB shares

Bug #22027 reported by Gabriel Bauman
20
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

I am using Breezy Badger (GNOME 2.12).

I've used 'Connect To Server' to add a number of public SMB shares to my Places
menu. As soon as I try to connect to them, Nautilus requests a password, even
though the shares are not password-protected. Clicking 'Cancel' in the
authentication dialog allows me to browse the shares and use them normally.

Also, browsing to the 'Network Servers' location causes multiple authentication
dialogs to pop up, one for each of the non-password-protected shares. Again,
clicking 'Cancel' in each dialog box allows me to see the list of network servers.

This behaviour is familiar to me - it happened in the pre-releases of Hoary as
well as in my former Gentoo GNOME installation (2.8). It was fixed when Hoary
released.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Some additional notes:

1. I am using browser mode.
2. The authentication dialog is the SMB-specific one (user, pass, domain) not
the keyring-unlock one.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Hmm, ok, I may have solved my own problem.

Clearing the user, domain, and password fields in the SMB auth dialog and saving
the null values in the keyring causes everything to work as expected. I guess I
just clicked 'OK' the first time I got the dialog and it saved my username and
workgroup in the keyring with no password, which caused authentication to fail
constantly.

Perhaps an 'anonymous windows share' profile in the 'Connect To Server' dialog
would avoid this kind of confusion? Pretty much all of the GNOME users in the
office here had the same trouble.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the comment. What is the issue with the current dialog? People just
don't put anything for the password if it's not required.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

(In reply to comment #3)
> Thanks for the comment. What is the issue with the current dialog? People just
> don't put anything for the password if it's not required

I first connected to an SMB share with a user/domain/password required. I then
added the shares that did not require usernames/passwords - but the user/pass
from the initial share were pre-filled in the dialog. So under the current UI, I
am required to clear the fields before clicking OK.

One way to fix this would be to disallow pre-filling of fields in the SMB auth
box. The other way might be the creation of an "Public Windows Share" connection
type in the Connect-To-Server dialog (as an analogue to the "Public FTP" and
"FTP (with login)" options). Both methods seem pretty cludgy.

Revision history for this message
Greg Michalec (greg-primate) wrote :

Hi -
I ran into this same problem - when browsing a network full of public shares,
you are inundated with password dialogs. Sure, you can save a blank username and
password for each server/share you encounter, but that's a pain - the whole
point of a publically browseable share is that you don't need to bother with a
password. Couldn't nautilus attempt by default to connect to a server with no
username/password, and if that fails, *then* put up a username/password prompt?

Revision history for this message
Daniel Holbach (dholbach) wrote :

*** Bug 22610 has been marked as a duplicate of this bug. ***

Revision history for this message
Daniel Holbach (dholbach) wrote :

Do you still encounter the problem in Dapper or Edgy?

Changed in nautilus:
assignee: seb128 → desktop-bugs
Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Sorry, I no longer have access to a Windows network with public shares on it to test with.

Revision history for this message
Daniel Holbach (dholbach) wrote :

I'm closing the bug now. If somebody can give more information on it, please reopen.

Changed in nautilus:
status: Needs Info → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.