GNOME Bugzilla – Bug 529365
doesn't allow to give extra credentials when connecting to shares
Last modified: 2015-02-25 08:00:30 UTC
The current code doesn't allow the user to authentificate when connecting to a share which is also anonymously available, the authentification might be required to get write access for example
I confirm this bug. When I browse the SMB network at work, I can see the computers connected and, if I want to browse one, I only see an empty window with 0 elements (at this point it should ask for my password like it was doing with Nautilus 2.20). Using gvfs-mount works perfectly.
In my opinion the issue described by Lionel is not the same as the original issue reported by Sebastien. I think that the issue described by Lionel might be the duplicate of Bug #524485. Anyway, I confirm the original issue. There is no way to provide authentication information thus gain more access to shares which are also anonymously accessible. It also does not work when I mount the share with explicit username from the command line: $ gvfs-mount smb://kpeter@duron/projects This succeeds and the desktop icon appears but I only get anonymous access. After opening the icon with nautilus an other mount is established: $ gvfs-mount -l Mount(0): projects ezen: duron -> smb://duron/projects/ Mount(1): projects ezen: duron -> smb://duron/projects/ Strange. I think that this second mount is anonymous and it is very bad...
Some detail hoping it will help: On my school network, all my samba servers have (amongst others) a public share (Samba logs me on as nobody, nogroup if credentials are not supplied) and a user share which (naturally) needs credentials. They are all security=user. This problem only appears on Hardy clents. W98, XPpro, Gutsy clients all work fine. I too get the 'not mounted' message but this looks like a timing problem - after getting the message I invariably find the share is now mounted, whether the public share or my user share. User shares give no problem as far as I can see. My credentials are collected and it all works. Public shares give a problem if my credentials are needed. For instance, in the public share is a staff_only folder. Even when I try to connect to public giving my user name, I end up as nobody, nogroup and so, of course, I cannot get into the staff_only folder. Hardy does not ask me for credentials. If I try to connect giving the staff_only folder as well as the public share name, Hardy does ask for my credentials. However, Hardy seems not to use them, and I still end up as nobody, nogroup and still cannot get into the folder. It seems as though Hardy looks to see if credentials are required, and if not, will not present them. The change I would hope to see is a reversion to Feisty-Gutsy behaviour which I never noticed because it just worked, but I think credentials were presented to samba if they were required OR IF THEY WERE OFFERED. If I give no UserName when connecting, I expect to be nobody, nogroup If I give a user name I expect my credentials to be verified with samba (currently they are not) and then to be username,primarygroup, even when connecting to a public share. My Sambas range from an old Mandrake to the latest Debian. Let me know if you need any config files etc. Chris
Has anyone been able to make any progress in this case? What sort of info would be required to sort this problem out?
You might want to take a look at https://bugzilla.redhat.com/show_bug.cgi?id=448008 which appears to regard the same issue and contains some debug info that might be useful for fixing this bug. Please let me know if there is anything else needed for fixing this. /Thomas
Is this bug really still unconfirmed? Or has this thread been abandoned as a duplicate? Or is there some doubt about whether it is a Gnome issue? It is still on my watch list.... Chris.
I can certainly confirm it on my end. I haven't been able to connect to Windows shares (through the gnome interface) since installing Fedora 9, which is the first Fedora to use the new gvfs way of doing things...
I can confirm this bug still exists in Hardy with all the updates installed.
(In reply to comment #2) > In my opinion the issue described by Lionel is not the same as the original > issue reported by Sebastien. I think that the issue described by Lionel might > be the duplicate of Bug #524485. > > Anyway, I confirm the original issue. There is no way to provide authentication > information thus gain more access to shares which are also anonymously > accessible. > > It also does not work when I mount the share with explicit username from the > command line: > $ gvfs-mount smb://kpeter@duron/projects > > This succeeds and the desktop icon appears but I only get anonymous access. > After opening the icon with nautilus an other mount is established: > $ gvfs-mount -l > Mount(0): projects ezen: duron -> smb://duron/projects/ > Mount(1): projects ezen: duron -> smb://duron/projects/ > > Strange. > I think that this second mount is anonymous and it is very bad... > Yes, I confirm this bug. If a share has anonymous read right access to all user, while someone user has read/write access to it. When you use gvfs-mount,even you input credentials of someone who has write access, you can still can not write to it in nautilus. Please fixed it ASAP!
I am still getting this bug and it is still valid on more recent releases, aka gvfs 1.2.2 on Ubuntu. Please increase version, gnome version, and mark confirmed. Thanks
It should be already fixed... *** This bug has been marked as a duplicate of bug 742169 ***