GNOME Bugzilla – Bug 86467
nautilus needs username/password configuration for smb://
Last modified: 2004-12-22 21:47:04 UTC
Package: nautilus Severity: enhancement Version: nautilus-1.0.6-15.ximian.14 Synopsis: nautilus needs username/password configuration for smb:// Bugzilla-Product: nautilus Bugzilla-Component: general Description: it would be nice if nautilus supported smb like konqueror did. plus, if things just worked like stepping into tar.gz packages and running rpms, etc.... ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-06-25 18:31 ------- Unknown version 1.0.x in product nautilus. Setting version to the default, "unspecified". Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.
nautilus has an authetication dialog. but gnome-vfs needs to support the hook for it so moving there. see related bug 44346. Triaging as major with normal priority based on the triaging of bug 44346.
The smb:// module itself is what needs the hooks. Re-assigning to the gnome-vfs-extras module where the smb: module is actually located.
Eh? It already does this. Closing.
sorry, not enough info in the entry. yes, nautilus supports samba--but only for public folders it appears. what it needs is a prompt for a username and password--and it'd be nice if you could set defaults somewhere as well.
Eh? Are you using the latest version which, at least for me and most people, prompts for password / username?
ok, found the problem i think. it looks like our samba shares allow anonymous login to get into the directory, but then do not provide read access. so nautilus doesn't prompt me for a username/password combo, but then can't access the directory. what we need is 1) a way to provide a default username/password instead of doing anonymous login, and 2) a way to ask it to always prompt me for a username/password.
i'm just rereading what i wrote. when i say there is no read access, what i mean is i can connect to the share with an anonymous login, but then i get an access denied error when i try to do an 'ls'. (this is trying to connect to the samba share using smbclient.
i can reproduce this exactly. is there any thought as to the best way to fix it?
A workaround would be to use uris like smb://username:password@smb_uri to access to your shares
Also, I'm not sure if this is related, but nautilus also seems to cache the user name and password you enter (which is fine if you enter it correctly). However, if you enter the wrong username and/or password nautilus will cache this wrong information, such that everytime you try to browse to that machine again it automatically uses the cached information. Once it has this info, there seems to be no way to over-ride it. not even smb://user:pass@machine seems to work. This on using nautilus 2.1.5 on redhat phoebe beta.
Alex Deucher: What version of gnome-vfs-extras did you use?
The ones that come with the redhat phoebe beta: gnome-vfs-extras-0.2.0-4 gnome-vfs2-extras-0.99.7-2
Created attachment 13846 [details] [review] here it is
It's a bug in nautilus. I had a patch for this in september :) Fortunately I found it, unfortuntalely, you probably can't apply it cause it's old. Actually, this patch fixes two bugs: Update username & password and "Don't ask password if user just selects a share in nautilus".
has this patch been applied to nautilus CVS? will it be included in gnome 2.2? it seems pretty trivial, and it apparently fixes an annoying bug.
I don't see how this patch affects smb. The first change just means we won't collect mime lists for any non-local directory. Its especially bad because it uses the (mostly bogus) gnome_vfs_uri_is_local function for this. This means any plugins that depend on mime lists (e.g. nautilus-media and others) stop working on e.g. NFS shares. I don't quite see the point. The other change i don't see how it ever could affect anything. get_info_file->details->get_info_error is never read unless details->get_info_failed is TRUE, which it won't be in this case. alexd: Are you claiming this patch in fact fixes a bug for you?
tambet, could you please explain the reasoning behind this patch?
First part of this patch is not relevant to this bug directly. It just makes browsing smb (and other password protected) shares more pleasant. Without this patch, if you just select a share in browse list, nautilus asks you it's password. Why? I don't plan to enter this directory, I just want to move over it to the next share! So you can't use nautilus with keyboard, unless you want to hit cancel on every share. It was matter of really annoying password dialog vs usable browsing without mime. I chose 2nd. Second part, one liner indeed fixes the problem this bug is about.
I commited something with the same effect as the second change to nautilus.
I haven't tried tambet's patch myself, I was only commenting on what he said.
FYI: I believe Redhat 9.0 ships with this bug. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88114 As a user (not a developer) I just want to mention the following: -Thanks for all the hard work -This bug sucks. :-)
I've done some searching and found multiple related bugs, which someone may want to mark as a duplicates (I'm not going to because it seems that the subject of this bug has changed over time, so I'm not sure what people want as a duplicate of this bug and what they want as a separate bug). Bug 110159 talks about the "Enter the password incorrectly once and you will be unable to access the share at all from within nautilus" problem. Bug 106722 talks about one user's problems with the smb:///username:password@host/share access method -- and also gives a number of possible suggestions on enhancements or ways to make the smb password stuff work right. Bug 114570 is also related and claims that the user is asked for the password for each and every file that they want to view. My own additional comments: I've had problems with the smb:// access method within nautilus since Red Hat 7.x all the way up to Red Hat 9--and also including the version of nautilus shipped with Ximian's Desktop 2. I recently discovered (last night) that running 'killall nautilus' in a terminal will allow me to get around the "Type your password wrong once and you won't be allowed to access that share ever again" problem. Due to these problems, I've felt forced to use smbclient (and read it's manpage several times to remember the syntax) from the command line each and every time I wanted to get files from a Windows NT share--and I told my wife to just ask me if she wanted to get the files. I really think this problem deserves to be high priority and major severity. I'm going to mark it as such. If someone disagrees, feel free to change it, but please explain to me why that isn't the correct priority/severity level.
This also looks related to bug 76646, though I don't know what webdav is and how/if it is related to smb. Bug 81482 (asking to cache smb authentications as well as asking to use some encryption method for smb passwords) is somewhat related as well.
Sorry for the spam. I just realized that I forgot to change the severity--doing so now.
*** This bug has been marked as a duplicate of 76646 ***