GNOME Bugzilla – Bug 529277
cannot mount smb share when its subdirs are accessible but its root not
Last modified: 2009-01-12 16:41:38 UTC
Please describe the problem: I'm regularly using a share called "DynStor/bar" on a "Windows Server 2003 3790 Service Pack 2" server (smbclient info) which works ok with gnomevfs and smbclient. gvfs doesn't like it though, it keeps asking for username and password. Note that my account has no access to the "DynStor" share, but only to the share "DynStor/bar". Steps to reproduce: access this "DynStor/bar" share using gvfs: $ gnomevfs-ls smb://host.dom.ain/DynStor/bar connection_message_func(): Callback CALLBACK: fill-authentication!!! connection_message_func(): Callback CALLBACK: fill-authentication!!! connection_message_func(): Callback CALLBACK: full-authentication!!! You must log in to access guest@host.dom.ain/DynStor Username (default "me"): <username> Domain (default "MSHOME"): <domain> Password: . (Directory, x-directory/normal) size 0 mode 0755 .. (Directory, x-directory/normal) size 0 mode 0755 foodir (Directory, x-directory/normal) size 0 mode 0755 $ gvfs-mount smb://host.dom.ain/DynStor/bar Password required for share dynstor on host.dom.ain User [me]: <username> Domain [MSHOME]: <domain> Password: Password required for share dynstor on host.dom.ain User [me]: <username> Domain [MSHOME]: <domain> Password: Password required for share dynstor on host.dom.ain <repeating forever> Actual results: asking forever for authentication information, although it is really correct Expected results: to get the smb location mounted and be able to do gvfs-ls or browse it using nautilus for that matter Does this happen every time? yes Other information: If I can do anything to shed light on this, please let me know. A workaround would also be very welcome, so I can upgrade to the latest GNOME without being stuck on the command-line.
Created attachment 109725 [details] smbc debugging output of gvfsd-smb when logging into share (anonymised) Ok, I compiled gvfsd-smb with smbc debugging and found that login probably works, but that gvfs fails when it cannot read the share's root.
Created attachment 109726 [details] smbclient debugging info when logging into share (anonymised) For comparison, here also smbclient's debug log for logging into the share and quitting immediately.
Ok, I'm beginning to understand the origin of this bug. When a new connection is made to an smb uri, the server's share is mounted first. The uri is taken to be smb://server/share/path. Mounting is known to be succeeded when the share's root has a successful smbc_stat operation (in do_mount(), gvfsbackendsmb.c around line 540). This fails when the share itself has no access permission (EACCESS/EPERM), which is the case for this specific share. The reason that this works with gnomevfs, is that it knows no mounting: it does authentication transparently when needed, and the operation that follows fails or succeeds. Accessing "smb://host.dom.ain/DynStor/bar", for example, does opendir on the directory "bar" on share "DynStor", which succeeds. Gvfs, however, first wants to mount "smb://host.dom.ain/DynStor" and does an smbc_stat on "DynStor" itself before it continues with "DynStor/bar". The former naturally fails in this situation. So, what should be done? I see two options - note that I'm not familiar with gnomevfs or gvfs, so I may be totally off, take it as a starting point. 1) Use another way to check if authentication succeeded, don't rely on the share's root to be accessible. It may require poking into libsmbclient's internals though, or libsmbclients needs some modification :( - don't take my word for it, I haven't found it but it may exist. 2) 'leak' requested directory to the mounting daemon gvfsd-smb so the really requested directory can be smbc_stat-ed instead; this option would seem less beautiful to me but can leave libsmbclient alone.
note that changing gvfsbackendsmb.c around line 530 in do_mount() (sorry, I poked too much to get the precise line number) from uri = create_smb_uri (op_backend->server, op_backend->share, NULL); to uri = create_smb_uri (op_backend->server, op_backend->share, "bar"); made the mount succeed, which shows that solution 2 would indeed work.
Created attachment 110326 [details] [review] patch which fixes issue I found a way to test if libsmbclient succeeded logging in or not. It's not documented (but I just can't seem to find any documentation), but seems to work: if a connection succeeded, it is cached. Caching is done by gvfsbackendsmb.c, so the cache is accessible. So that is done instead of checking the return value of smbc_stat. I tested it with command-line tools and that seems to work; still testing how nautilus behaves.
Nautilus is working allright too. I'm using this patch on a daily basis. I have contacted the samba-technical mailing list on this issue. It would be nice to be able to ask libsmbclient if authentication succeeded. http://lists.samba.org/archive/samba-technical/2008-May/059333.html
Ok, after some discussion samba-technical I found a way see if authentication worked or not, independent of the readability of the share's root. errno is set to EPERM if authentication failed, and to EACCES if it's just unreadable but authentication succeeded. But there's a catch here: EPERM is only returned if the session setup failed, which succeeds for the anonymous user. This means that first the requested username should be used in logging in. That's where I'm currently stuck. I'd say the way to find out if login succeeded or not is to ask libsmbclient. This also enables us to report to the user know what's going on exactly. I'm willing to work with upstream to get it fixed if needed and use a workaround in the meantime (probably the patch above, ifdef-ed on samba version). What do you guys see as the direction forward, does it make sense to ask libsmbclient if authentication succeeded, or is another way better?
p.s. I see some trouble disappearing when the first item mentioned in http://mail.gnome.org/archives/gvfs-list/2008-May/msg00005.html is solved. Specifically, the apparent login success of anonymous would not happen if the supplied credentials are tried right away.
Is this bug still relevant, after all the smb rework that has recently landed ?
It's been working for me for a while (since early in the fedora 10 development process)
I have no access anymore to the original windows share and cannot reproduce it here with samba right now, sorry.
I have a feeling this is still not fixed, though we were not able to build an environment to reproduce the issue. If you know how to simulate this, feel free to reopen this bug.