Red Hat Bugzilla – Bug 448008
cannot connect to windows share
Last modified: 2015-03-03 17:32:46 EST
Description of problem:
It is not possible to mount windows shares via nautilus ("connect to server",
No matter what kind of credentials I provide it with, it fails. I've seen two
distinct error messages. The first appears upon creating the share, the second
on subsequent attempts to access the share by clicking the created icon.
Can't display location "smb://someserver.example.com/sharename/"
The specified location is not mounted
The folder contents could not be displayed.
You do not have the permissions necessary to view the contents of "sharename on
Clicking the initially created also triggers the creation of a second icon,
which appears like a copy of the first. I have never seen more that one
additional icon (two total) from this bug.
My permissions are fine for accessing the share and connecting through smbclient
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch "Connect to Server" wizard
2. Choose to connect to a Windows share
3. Add info that should allow access to a valid windows share
Please let me know what kind of info you need and I'll provide you with it. :)
Any news regarding this problem? It's still an issue here...
I can connect to other cifs devices (NAS, Samba) but it fails on every Windows
share I've tried...
I'm on libsmbclient-3.2.0-2.17.fc9.i386, kernel-22.214.171.124-76.fc9.i686,
Just changed the component to gvfs, since that is probably more correct...
gvfs-mount doesn't work either and I believe that is the backend for this stuff?
If i'm mistaken, please enlighten me...
This is a know issue and fix is being work on.
In meantime, could you please check if you can get to your windows shares via
Also, the new gvfs version (0.2.5) has debug printouts turned on, can you please
run '/usr/libexec/gvfsd -r' in terminal and attach the debug output here?
(please note you may want to mask some personal informations from the output)
I can connect using smbclient without problems.
Created attachment 311428 [details]
gvfsd -r output showing the problem as it happens
Any progress on this bug? Anything else I can provide you with to help?
*** Bug 234819 has been marked as a duplicate of this bug. ***
I have seen this too, but not in the general case, in one very specific one (which I haven't quite nailed down). The interesting thing is that as far as I can tell it only affects one user, so it appears not to be a server configuration directly but may be some kind of obscure Active Directory thing. (The user *does* have full privileges to the share in question)
A workaround seems to be to use the directory in ~/.gvfs/ which, surprisingly (at least in my case) *is* mounted. Weird that it is mounted in ~/.gvfs yet Nautilus doesn't see it...
Not sure if I fully understand your last comment. The ~/.gvfs/ directory is a mountpoint for gvfs-fuse, which exposes active gvfs mounts. You should see a subdirectory like 'share on server' and 'gvfs-mount -l' should list the mount adding full uri to it (smb://server/share/).
If you can see this, you should be able to access the share in Nautilus. Please post any errors if that's not true.
I just tried, what Tim suggested and it works exactly like he says here too.
- I complete the "Places -> Connect to Server" wizard
- I get the error stating: "can't display location 'smb://server/share' - the specified location is not mounted.
- I run gvfs-mount -l where I actually do see : Mount(0): share on server -> smb://server/share/
- I go to ~/.gvfs/ where a "share on server" actually exists
- I can cd into "share on server" from where I can list and work with all the files
- Now double-clicking the connection icon that has been created on my desktop, I get the second error "The folder contents could not be displayed - you do not have the permissions necessary to view the contents of share on server"
- checking gvfs-mount -l now reveals a second Mound(1) entry, identical to the first. (it's listed twice - Mount(0) and Mount(1))
- the same goes for ~/.gvfs/ - the folder appear twice in there (with identical name) and I can no longer cd into the directory.
Hope this helps to clear something up?
(In reply to comment #9)
> The ~/.gvfs/ directory is a
> mountpoint for gvfs-fuse, which exposes active gvfs mounts.
> If you can see this, you should be able to access the share in Nautilus.
Yep, I know it *should* be possible and that it doesn't really make sense that Nautilus doesn't see it; that's why I said it was "weird" :-) To be crystal clear, I do regularly see situations where ~/.gvfs/[sharename] is working fine (=works normally, possible to read/write/list etc.), and the share appears in Nautilus's list but it isn't possible to access it via Nautilus and it gives errors like the ones in the original bug here. I previously assumed it was some random local configuration error, but since other people seem to be seeing it then maybe it's not.
> Please post any errors if that's not true.
I think that's what the original bug is
Anyway, unfortunately I'm not able to reproduce that right now (as I said, it's on a specific user account in a specific environment - and that's not mine unfortunately), but I will do next time I see it. If there are any debugging commands that I can run (other than "gvfs-mount -l" which I will run next time, although I assume it's going to report the share as mounted, given that it's possible to read and write to ~/.gvfs/[sharename]), let me know.
For more debugging information, just yell! The problem is 100% reproducible on all my servers and shares (that I've tried) here, since F9 was released.
So is this bug actually in a completely different component? It seems like, behind the scenes, gvfs is working. OTOH, I don't know exactly how these things are interconnected, so...?
gvfs-1.0.3-2.fc10 has been submitted as an update for Fedora 10.
If possible, please test the updated packages (Fedora 10 only), read the notes posted in the link above and report any issues.
Fedora 9 packages will follow soon, after we gather some feedback from the testing.
This has been working on Fedora 10 since early in the pre-release phase so I've only ever had this particular issue on Fedora 9. That said, I'll update my Fedora 10 system and let you know how it goes...
gvfs-1.0.3-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update gvfs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-10848
gvfs-1.0.3-3.fc10 has been submitted as an update for Fedora 10.
gvfs-1.0.3-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update gvfs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11176
448008 has been resolved since F10 Pre?? and this update does not appear to have any regressions in this regard. Things are still all nice and dandy for me. :-) Thanks
gvfs-1.0.3-4.fc10 has been submitted as an update for Fedora 10.