I have configured a samba share in my local network accessible with my username, but without a password. "smbclient //$SERVER/$share" gets me into the share without problems so doess a manual navigation in dolphin to "smb://$SERVER/$share" works. But I can't open the share through the mouse or enter or anything else. It seems like that opening the share that way, will lead to the root path of the server Here is the log I get while trying to open it: Jun 09 20:38:35 pingu kdeinit5[3028]: kio_smb: QUrl( "smb://$SERVER/" ) Jun 09 20:38:35 pingu kdeinit5[3028]: kio_smb: updateCache "/" Jun 09 20:38:35 pingu kdeinit5[3028]: kio_smb: auth_smbc_get_dat: set user= karol , workgroup= KAROLSSTUFF server= $SERVER , share= IPC$ Jun 09 20:38:35 pingu kdeinit5[3028]: kio_smb: libsmb-auth-callback URL: QUrl( "smb://$SERVER/IPC$" ) Jun 09 20:38:35 pingu kded5[4150]: org.kde.kio.kpasswdserver: User = "karol" , WindowId = 0 Jun 09 20:38:35 pingu kdeinit5[3028]: kio_smb: got password through cache maybe the issue is, that IPC$ is opened, because in smbclient I get "NT_STATUS_NETWORK_ACCESS_DENIED listing \*" "smbclient -L //$SERVER/" does list me both "shares" the IPC$ and the real disk one. Reproducible: Always Steps to Reproduce: 1. navigate to share 2. (double) clicking it 3. nothing happens
using Version 14.12.95
actual built from git master
Thanks for the bug report, please provide the version of kdelibs or KIO if you are use KF5. Thanks!
Does smb://$SERVER show all the available shares on $SERVER?
(In reply to Emmanuel Pescosta from comment #3) > Thanks for the bug report, please provide the version of kdelibs or KIO if > you are use KF5. Thanks! KIO-5.10 and kio-extras 5.3.1 (In reply to Emmanuel Pescosta from comment #4) > Does smb://$SERVER show all the available shares on $SERVER? yes, but there is only one anyway. I have actually access to three different samba servers here: 1. my machine with samba-4 installed 2. a windows 7 machine with two shares 3. a fritz.box with the usual NAS share I can access the first and second samba server in dolphin as expected, but the fritz.box not. I think it may have something todo with authentication, because the fritz.box requires it, even without a password. So there are users equal to the ones on the machines, so that it is browsable without having a prompt, which does work if the URL to the actual share is typed in manually or in smbclient. Wait a second... I think I know what the issue is: The workgroup, the server and the share name are equal for the fritz.box, which may lead to navigation problems?
yes, it seems to work after changing the workgroup of the server, allthought now I have some caching problems, because the old workgroup name is still used, but that's the server. anyhow, the problem seems to be having the same workgroup name and share name
I am not sure that can be fixed exactly. https://www.iana.org/assignments/uri-schemes/prov/smb notably smb://workgroup (workgroup) and smb://workgroup (server) cannot be differentiated and there is no syntax that can express this to the extend that we'd need to. For manual navigation (clicking through the tree) we possibly can use the domain prefix syntax. smb:// smb://workgroup smb://workgroup;@workgroup <-- new, unambiguous smb://workgroup;@workgroup/fanycshare1 smb://workgroup;@workgroup/fanycshare2 As a side effect manually entering smb://workgroup would always list the workgroup when there is name collision, which I guess in the end solves the problem as a whole as from there you can then descend into smb://workgroup;@workgroup which is again unambiguous.
Mh at least on my dated libsmbc that doesn't actually work as planned. It kinda parses the uri correctly (the auth callback has the correct workgroup and server values) but then still trips internally when listing. So, I think you'll also need to file a bug report against samba. smbc_opendir with `smb://workgroup;@workgroup` must open the SERVER workgroup not the WORKGROUP workgroup in this scenario. I am guessing it simply ignores the defined domain since it shouldn't ordinarily factor into the listing, same name is pretty much the only scenario where this is not true.
I've talked with one of the upstream devs and we've concluded that it isn't worth pursuing a more involved code change for this. It's not really a supported use case to have conflicting names from the samba side. We suggest you change one of the names as it's bound to be way more compatible with any software.