Ive noticed this painful bug. I have a public share with read/write access on a remote server. From the LAN under gnome and unity etc I can write to the folder. Dolphin will not let me write to the same folder. However, if there is a subdirectory in that share, it can write inside that directory. In the example bellow, under gnome, unity i can write to /share and /downloads folder. Dolphin cannot write to either, but can read. If a folder exists for example /share/NewFolder/ then Dolphin can write to that folder without issue... Example SMB setup: # for all [global] workgroup = WORKGROUP netbios name = server security = user null passwords = true force user = server force group = server force create mode force directory mode create mask = 0755 directory mask = 0755 guest account = nobody guest ok = yes only guest = yes map to guest = Bad User browsable = yes public = yes # read + write [Downloads] path = /home/server/Downloads writeable = yes [Share] copy = Downloads path = /mnt/server/Share
Absolutely the same! Gento amd64~ KDE Plasma 5.9.2 KDE Framework 5.31.0 Qt 5.7.1 Dolphin 16.12.2
Same here. Happened before and after installing samba package. x86_64 Linux 4.9.11-1-ARCH plasma-desktop 5.9.2-1 dolphin 16.12.2-1 This bug behaves the same when accessing my old NAS drive and in my new Windows PC. In the base folder I can still delete and rename files, but the paste and create new options are greyed out. When trying via drag and drop it shows: Access denied. Could not write to . If I create a new folder in the working subfolder, that new folder wil also fail, but if I paste by right clicking that new folder from the working subfolder, it works. If I run Windows 10 in VirtualBox, with the network setting in bridged mode, everything works perfectly.
It looks like samba doesn't set write permission to the root folder: kio-extras/smb/kio_smb_browser.cpp has two occurrences of: udsentry.insert(KIO::UDSEntry::UDS_ACCESS, (S_IRUSR | S_IRGRP | S_IROTH | S_IXUSR | S_IXGRP | S_IXOTH)); One of them (or both) needs to set the write permission flag. Same bug is in mtp:// and is fixed by https://phabricator.kde.org/D4839 Unfortunately I don't use samba so I can't test the fix there.
*** Bug 377126 has been marked as a duplicate of this bug. ***
I notice it : - When there are files or directories in the shared folder, I can't don't have write access to the root of the shared folder. - When the shared folder is empty (no files, no folders), then I have write acces to the root of the shared folder. - In subfolders of the shared folder, I almost always have write access. Thank you
*** Bug 377198 has been marked as a duplicate of this bug. ***
Hi, I can confirm I have this same issue on my computer. openSUSE LEAP 42.2 KDE Plasma 5.8.6 KDE Framework 5.26.0 Qt 5.6.1 Dolphin 16.08.2 Is there a way I can help to fix this?
Seeing this as well on a fresh install of KDE Neon User LTS.
*** Bug 378563 has been marked as a duplicate of this bug. ***
Hello, Just wondering... Why is this bug still in "UNCONFIRMED" Status ?? The bug has been reported here many times, and on duplicates as well...
(In reply to mathojojo from comment #10) > Hello, > > Just wondering... Why is this bug still in "UNCONFIRMED" Status ?? The bug > has been reported here many times, and on duplicates as well... I agree with you... many people have the same issue but this bug seems to be forgotten :(
(In reply to fbr from comment #11) > (In reply to mathojojo from comment #10) > > Hello, > > > > Just wondering... Why is this bug still in "UNCONFIRMED" Status ?? The bug > > has been reported here many times, and on duplicates as well... > > I agree with you... many people have the same issue but this bug seems to be > forgotten :( Changing the status to confirmed would be pointless. Either there is a dev who uses samba and is motivated to fix this bug, or the bug will stay there (even if you mark it as confirmed).
(In reply to Elvis Angelaccio from comment #12) > (In reply to fbr from comment #11) > > (In reply to mathojojo from comment #10) > > > Hello, > > > > > > Just wondering... Why is this bug still in "UNCONFIRMED" Status ?? The bug > > > has been reported here many times, and on duplicates as well... > > > > I agree with you... many people have the same issue but this bug seems to be > > forgotten :( > > Changing the status to confirmed would be pointless. Either there is a dev > who uses samba and is motivated to fix this bug, or the bug will stay there > (even if you mark it as confirmed). You are right but I can't believe that no devs use samba :). However it is not a good point for KDE in some contexts : For example I use KDE for my work in my company and this kind of problems can be very impacting and could be a "motivation" to switch to another DE. KDE is really good, I don't want to change :)
I have found a workaround: When you login with "*" for both user and password for a share which doesn't require a password, add another "*" to the adress. Example: You have opened a share and the adress looks like this: smb://*@pcname/sharename/ Change it to smb://*:*@pcname/sharename/ and press enter. Voila, you should have write access. Can this please get fixed? It should be so easy and it's really annoying...
Thank you, I use a workaround too : I use ftps ;) But using a workaround is not a deal. And I really think that a network protocols should have a high priority in a DE. More and more NAS, multimedia servers ... are making use of : - SMB (bad implementation on KDE) - NFS (not implemented in KDE... incredible, but true....) - DLNA/uPnP : there was a kio package for that, but I never successed to use it It's really not serious for a DE. I don't know how all of this is working on Gnome (never tried, because I'm an early fan of KDE, and plasma), but network protocols are a just weak and poor on KDE, and it's a big anomaly. I still hope a developper will fix it (and if he could work on NFS, and DLNA/uPnP .... would be great)
openSUSE 42.2 here and can confirm I also have this bug. I have literally wasted hours messing around with smb.conf and trying various permission states. I am disappointed to see this as "unconfirmed" but glad to see others have the same issue as me and its not just something I was doing wrong. I have an opensuse server, a windows desktop and an opensuse laptop. Windows desktop seems to be able to access the server and read/write just fine. Opensuse laptop with KDE has issues and cannot write to the root level dirctory as others have mentioned.
If it was easy to fix, someone actually (still?) using Samba could trace/analyze the code and check where it fails. Otherwise we cannot even confirm _where_ the bug is, so no need to change the bug status. Note that I know of no KDE developer using Samba, so unless someone steps in, this will probably not be fixed.
(In reply to Christoph Feck from comment #17) > If it was easy to fix, someone actually (still?) using Samba could > trace/analyze the code and check where it fails. > > Otherwise we cannot even confirm _where_ the bug is, so no need to change > the bug status. > > Note that I know of no KDE developer using Samba, so unless someone steps > in, this will probably not be fixed. @Christoph Feck Hello Christoph, If none of KDE developers are making use of Samba, what network file sharing protocol are they using ? NFS ? No, NFS is not implemented an integrated in Plasma at all. I can't believe that they don't use any NAS or Network Multimedia Drives. The status is that, if you have a NAS (so you need to copy/paste drag&drop files into it, from your computer), you should avoid KDE Plasma. It's a very bad signal !
I can only speak for myself, but I only used sftp:// which is based on ssh.
Two other workarounds: 1.: Mount a networkfolder to make it look like it was local to Plasma. Via terminal: sudo mount -t cifs -o username=*,password=*,uid=1000,gid=1000,file_mode=0660,dir_mode=0770 //hostname.local/sharename/ /home/user/mountfolder/ Permanent via fstab: //hostname.local/sharename/ /home/user/mountfolder/ cifs defaults,username=*,password=*,uid=1000,gid=1000,file_mode=0660,dir_mode=0770 0 2 Or 2.: Install a GTK file browser like Thunar with gvfs + gvfs-smb (+gnome-keyring for saving login data). With it you can drag & drop stuff from and into SMB shares or open media files without having to fully copy them first.
I can confirm this bug with Synology DS111 DSM 6.0. Unable to write to root level of the share. Error: Access denied. Could not write to . Sadly, implementation of network filesystems in KIO is very very poor. Also missing correct NFS implementation badly.
Just faced the same bug, but workaround from @tempel.julian does not work well. I finally have write access to my Windows share (requires auth) but if I create with dolphin a subdirectory I can't open it. It requires authentication again but this time the same login/password do not work anymore. Another glitch. If I don't use *:* for auth but just smb://host/share and login via popup dialog, then I create a subdirctory in cifs mounted directory for the same share, I can open the new subdirectory with Dolphin, but again no write access inside. But if I write a few files from console (the same mounted cifs) to the subdirectory I magically obtain the write access from Dolphin. I also tested with "mount cifs" and it works in all circumstances where dolphin fails.
I believe I have been seeing this too but in a somewhat different setup. There are multiple shares with different access permissions set up on the server in question. I have no problems accessing my de-facto "home" folder, I do, however, get no write access to another folder even though the permissions set by Samba and the underlying FS seem to be correct. If I either mount the share manually or try to write to in from Windows there is no problem. Here is a relevant excerpt from smb.conf: [home] # This one works path = /mnt/storage/home valid users = @ECHMET_Users browsable = yes writable = yes read only = no force create mode = 600 force directory mode = 700 create mask = 700 directory mask = 700 [everyone] # This gets no write access through KIO path = /mnt/storage/everyone valid users = @ECHMET_Users browsable = yes writable = yes read only = no force create mode = 660 force directory mode = 770 create mask = 660 directory mask = 770 force group = ECHMET_Users KF5 5.34, KDE Apps 17.04.1, up-to-date Arch Linux. Since I need this working quite badly at work, can anybody at least point me where to look in the SMB KIO source?
Getting any debug output from kio_smb has proven to be next to impossible so I took a bit of an educated guess. Can you guys try the attached patch, it seems to work for me.
Created attachment 105680 [details] Allow write access to root samba share
(In reply to madcatx from comment #25) > Created attachment 105680 [details] > Allow write access to root samba share Id be happy to try this, but I dont know how to make the kio-extras package (https://github.com/KDE/kio-extras)..... Whats the command line used to build and install this? Im on Arch...
Created attachment 105682 [details] Allow write access to root samba share The code still does not work entirely as expected - I am allowed to try to write into server shares or workgroup listing which is obviously nonsensical and the code seems to try to prevent that, it just does not work. I cannot investigate this any further unless I can pry some debugging output out of the smb_kio plugin. The problem of unwritable share root seems to be gone though.
Created attachment 105683 [details] Patched Arch Linux PKGBUILG Archers are welcome to try this patched PKGBUILD.
Comment on attachment 105680 [details] Allow write access to root samba share >diff --git a/smb/kio_smb_browse.cpp b/smb/kio_smb_browse.cpp >index 67e2fa09..7092e41c 100644 >--- a/smb/kio_smb_browse.cpp >+++ b/smb/kio_smb_browse.cpp >@@ -381,7 +381,7 @@ void SMBSlave::listDir( const QUrl& kurl ) > udsentry.insert( KIO::UDSEntry::UDS_FILE_TYPE, S_IFDIR ); > > // Set permissions >- udsentry.insert(KIO::UDSEntry::UDS_ACCESS, (S_IRUSR | S_IRGRP | S_IROTH | S_IXUSR | S_IXGRP | S_IXOTH)); >+ udsentry.insert(KIO::UDSEntry::UDS_ACCESS, (S_IRWXU | S_IRWXG | S_IROTH | S_IXOTH)); > > if (dirp->smbc_type == SMBC_SERVER) { > // QString workgroup = m_current_url.host().toUpper();
If you want the developers to look at the patch, please submit it to https://phabricator.kde.org. Patches in Bugzilla unfortunately tend to get lost.
(In reply to madcatx from comment #28) > Created attachment 105683 [details] > Patched Arch Linux PKGBUILG > > Archers are welcome to try this patched PKGBUILD. I get the following error with the PKGBUILD (just running makepkg from cmd): kio-extras-17.04.1.tar.xz ... FAILED (unknown public key 3A6A4DB839EAA6D7) ==> ERROR: One or more PGP signatures could not be verified!
cant edit my last comment. Got around it with: gpg --recv-keys 3A6A4DB839EAA6D7
ok ive ran the makepkg command(assuming this also will install the package). Rebooted, and still have the same bug present in dolphin...
There has got to be something else going in. kio_smb sets the permissions on the UDSEntries correctly but Dolphin seems to have a mind of its own.
(In reply to madcatx from comment #27) > Created attachment 105682 [details] > Allow write access to root samba share > > The code still does not work entirely as expected - I am allowed to try to > write into server shares or workgroup listing which is obviously nonsensical > and the code seems to try to prevent that, it just does not work. I cannot > investigate this any further unless I can pry some debugging output out of > the smb_kio plugin. kio_smb's debug output comes from kdeinit5. You should be able to get it from journalctl, but you need to enable it first: make sure you add [Rules] kio_smb.debug=true in ~/.config/QtProject/qtlogging.ini Then "journalctl -b | grep kio_smb" should give you what you want.
Thanks, I figured that the logs are dumped through systemd already. This still does not answer the question where does Dolphin get the access permissions info from. Either some other layer messes with them along the way or the UDSEntry::ACCESS is not the source of access permissions used by Dolphin. As far as the debug output tells me, kio_smb with my patch sets the access permissions correctly. I believe that this is the actual root cause of the problem. I gave it a quick spin on another machine at work where this has been acting up and somehow miraculously I could write into the usually unwritable share this morning. Note that the machine runs vanilla Fedora 25 with no custom patches anywhere. As far as I can tell *something* randomly makes the root share look unwritable for whatever reason.
> kio_smb sets the permissions on the UDSEntries correctly but Dolphin seems to have a mind of its own. In other words, using Dolphin copying fails, but using "kioclient5 cp" works?
Created attachment 105687 [details] Debugging patch If there is anybody able to reproduce the problem reliably, there is a small testing patch that dumps the access permissions set by smb_kio into the system log. In order to see the debugging info, launch "kdebugdialog5", make sure that "kio_smb" is checked, restart Dolphin, try to access your samba shares and post the output of "journalctl -b | grep kio_smb". systemd-less distributions might dump the info into the terminal instead. Thanks.
(In reply to Christoph Feck from comment #37) > > kio_smb sets the permissions on the UDSEntries correctly but Dolphin seems to have a mind of its own. > > In other words, using Dolphin copying fails, but using "kioclient5 cp" works? I just got it to happen again and yes, this is exactly the case. The patch to set the UDSEntry access still seems to be needed but it is not the only issue at play here. It seems that it may have something to do with login credentials. This is how I managed to trigger the problem: I accessed a share that is usually unwritable. In this particular instance everything seemed to be OK and I could write into it through Dolphin. I opened a directory in that share and got asked for my login credentials again for some reason. Until I OK'ed the creds prompt, the "Create new" item in the rightclick menu in Dolphin was greyed out. When I returned back to the share's root, the write access to it from Dolphin was gone by kioclient worked. Weird...
For some reason in my case attempt to access smb share eats 4 cores at 100% 3317 marsark 20 0 527504 26620 22188 R 100,0 0,2 0:32.47 smb.so 3305 marsark 20 0 527500 26616 22188 R 99,7 0,2 0:32.56 smb.so 3306 marsark 20 0 527504 26620 22188 R 99,7 0,2 0:32.60 smb.so 3318 marsark 20 0 527500 26616 22188 R 99,7 0,2 0:32.51 smb.so I successfully build kio-extra with debug patch. I will test it against my Synology NAS.
Would this patch also fix the behavior that files like large videos are first copied to the client system before they can be watched? This is another _HUGE_ restriction of the current Samba share support of KDE.
I've done a bit more thorough investigation to see how the access permissions on UDSEntry actually propagate. Here is what I can tell so far: Current behavior: When browsing a Windows network in Dolphin, you can: - Rightclick a Workgroup, Server or Share. You will get a context menu with the "Create new" item greyed out. - Rightclick anywhere in the empty space, this should give you the same menu with the "Create new" item available. - When things break, the "Create new" item will be greyed out even when you rightclick into the empty space with a Share's root open in Dolphin. This is a result of Dolphin thinking that the location is not writable. Any other means of writing into that location (drag-n-drop, CTRL+C - CTRL+V, ...) will not work either. This is the problem we are trying to solve here. Behavior with my patch: - Rightclicking a Share shall give you a menu with the "Create new" item accessible. Creating a file in the Share this way or dropping a file onto the Share should work. - If you open the Share and try to write into it, it will still be broken. What you can test: 1) Apply the patch and navigate to the list of Shares on your server in Dolphin. 2) Rightclick one of your "unwritable" shares, go to "Create new->Text file" and check if you can write into the share this way. Alternatively you can drop a file onto the Share. If you do it like this you should have write access. - If your Share requires a valid username/pass combo, *enter the Share first*, wait until you are asked for the login credentials, authenticate yourself, go one level up and only then try to write into the share. Yes, really. These findings are valid for a Fedora 25 client (kio-extras 16.12 with no Red Hat clever patches) and CentOS 7 samba 4.4 server with user accounts checked against Windows AD. Bottomline: smb_kio will benefit from my patch but it does not really fix the issue at hand as it seems to be a Dolphin bug.
(In reply to Luca Beltrame from comment #30) > If you want the developers to look at the patch, please submit it to > https://phabricator.kde.org. Patches in Bugzilla unfortunately tend to get > lost. Is it just me or is there currently no obvious way how to get a phabricator account? Thanks...
(In reply to madcatx from comment #43) > Is it just me or is there currently no obvious way how to get a phabricator > account? Thanks... Please register on identity.kde.org, then you can use the "Login with LDAP" form of Phabricator.
I have discovered that konqueror works fine. I can make folders with it, change names etc. Nothing is greyed out in the root share. This is without any patch or anything. Interestingly enough konquerors file management is supposedly provided by dolphin: https://forum.kde.org/viewtopic.php?f=22&t=127884#p374651
@madcatz: it's unlikely that the bug is in Dolphin, as other kioslaves work just fine. Dolphin enables/disables the "Create New" menu depending on KFileItem::isWritable(). You may want to put some debug prints in that function (which is in kio/src/core/kfileitem.cpp)
Fixing assignee to plasma-bugs, otherwise this spams the main Plasma list and screws up filters.
(In reply to madcatx from comment #38) > Created attachment 105687 [details] > Debugging patch > > If there is anybody able to reproduce the problem reliably, there is a small > testing patch that dumps the access permissions set by smb_kio into the > system log. > > In order to see the debugging info, launch "kdebugdialog5", make sure that > "kio_smb" is checked, restart Dolphin, try to access your samba shares and > post the output of "journalctl -b | grep kio_smb". systemd-less > distributions might dump the info into the terminal instead. > > Thanks. I cant figure out how to apply this patch. Can you put together another pkbuild with this? That one worked a treat
(In reply to Elvis Angelaccio from comment #46) > @madcatz: it's unlikely that the bug is in Dolphin, as other kioslaves work > just fine. Dolphin enables/disables the "Create New" menu depending on > KFileItem::isWritable(). You may want to put some debug prints in that > function (which is in kio/src/core/kfileitem.cpp) Okay, I will have a look now that I know where to dig. Stay tuned.
(In reply to Bronson from comment #48) > (In reply to madcatx from comment #38) > > Created attachment 105687 [details] > > Debugging patch > > > > If there is anybody able to reproduce the problem reliably, there is a small > > testing patch that dumps the access permissions set by smb_kio into the > > system log. > > > > In order to see the debugging info, launch "kdebugdialog5", make sure that > > "kio_smb" is checked, restart Dolphin, try to access your samba shares and > > post the output of "journalctl -b | grep kio_smb". systemd-less > > distributions might dump the info into the terminal instead. > > > > Thanks. > > I cant figure out how to apply this patch. Can you put together another > pkbuild with this? That one worked a treat You can just replace the old patch with the debug one. If you give it the same name as the original patch, the PKGBUILD should work.
Not sure what information you need, but heres the last slab of the log... journalctl -b | grep kio_smb May 25 22:18:26 brons kdeinit5[1107]: kio_smb: QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1107]: kio_smb: checkURL QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1107]: kio_smb: checkURL return3 QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= bronson , workgroup= WORKGROUP server= server , share= Share May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1106]: kio_smb: QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1106]: kio_smb: updateCache "/Share" May 25 22:18:26 brons kdeinit5[1106]: kio_smb: we don't really need to authenticate for this top level url, returning May 25 22:18:26 brons kdeinit5[1107]: kio_smb: open "smb://server/Share" 3 10000 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name . "." ' "" ' 7 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name .. ".." ' "" ' 7 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name Zac Poonen "Zac Poonen" ' "" ' 7 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share/Zac Poonen" May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= bronson , workgroup= WORKGROUP server= server , share= Share May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1107]: kio_smb: size 0 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name share "share" ' "" ' 7 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share/share" May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= bronson , workgroup= WORKGROUP server= server , share= Share May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: QUrl("smb://server/Share") May 25 22:18:26 brons kdeinit5[1107]: kio_smb: size 0 May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir May 25 22:18:35 brons kdeinit5[1107]: kio_smb: QUrl("smb://server/Share") May 25 22:18:35 brons kdeinit5[1107]: kio_smb: updateCache "/Share" May 25 22:18:35 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= bronson , workgroup= WORKGROUP server= server , share= Share May 25 22:18:35 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: QUrl("smb://server/Share")
(In reply to Bronson from comment #51) > Not sure what information you need, but heres the last slab of the log... > journalctl -b | grep kio_smb > > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: checkURL > QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: checkURL return3 > QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= > bronson , workgroup= WORKGROUP server= server , share= Share > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: > QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1106]: kio_smb: QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1106]: kio_smb: updateCache "/Share" > May 25 22:18:26 brons kdeinit5[1106]: kio_smb: we don't really need to > authenticate for this top level url, returning > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: open "smb://server/Share" > 3 10000 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name . "." ' "" ' > 7 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name .. ".." ' "" ' > 7 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name Zac Poonen "Zac > Poonen" ' "" ' 7 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share/Zac > Poonen" > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= > bronson , workgroup= WORKGROUP server= server , share= Share > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: > QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: size 0 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: dirp->name share "share" > ' "" ' 7 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share/share" > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= > bronson , workgroup= WORKGROUP server= server , share= Share > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: > QUrl("smb://server/Share") > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: size 0 > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: updateCache "/Share" > May 25 22:18:26 brons kdeinit5[1107]: kio_smb: smbc_readdir > May 25 22:18:35 brons kdeinit5[1107]: kio_smb: QUrl("smb://server/Share") > May 25 22:18:35 brons kdeinit5[1107]: kio_smb: updateCache "/Share" > May 25 22:18:35 brons kdeinit5[1107]: kio_smb: auth_smbc_get_dat: set user= > bronson , workgroup= WORKGROUP server= server , share= Share > May 25 22:18:35 brons kdeinit5[1107]: kio_smb: libsmb-auth-callback URL: > QUrl("smb://server/Share") The output doesn't seem to contain the info I need. Can you dump the whole smash like this - journalctl -b | grep kio_smb > smb_debug.txt - and post it somewhere? The info about share access permissions should pop up in the log when you open the server's root. You can run journalctl -f and look what gets logged when you browse your shares.
full log here: https://pastebin.com/H4eP8cnR Im not sure your patch applied correclty...
Git commit 550e6915b4a3683206af21651a1335df97d4b3aa by Elvis Angelaccio, on behalf of Michal Malý. Committed on 10/07/2017 at 17:33. Pushed by elvisangelaccio into branch 'Applications/17.04'. Allow write access to Samba Shares' root Summary: kio_smb plugin sets Samba Shares as read-only which results in incorrect behavior when a user tries to write into a share. Reviewers: elvisangelaccio Differential Revision: https://phabricator.kde.org/D5947 M +5 -3 smb/kio_smb_browse.cpp https://commits.kde.org/kio-extras/550e6915b4a3683206af21651a1335df97d4b3aa
Just tested this change from git. Works good. Thanks :)
I did some more digging to figure out how KIO works under the hood and where it makes Dolphin think that some of the Samba shares are not writable. Here is what I found out so far: Apparently every KIO directory is supposed to have a "." UDSEntry. If it is not there, KIO tries to save the day and creates a default one. kio_smb does not create the "." entries and relies on the KIO framework to handle this. I am uncertain what implications this could have. Additionally, there is a case where kio_smb signals both finished() and error() to KIO which is apparently not allowed. Without my previous partial fix applied, I could perfectly reproduce the following behavior: - Samba server is opened, the root directory which contains all of the individual shares incorrectly appears as writable in Dolphin - Upon opening the first share, Dolphin uses the default-created "." UDSEntry which has perms set to 775 and the share appears writable - Upon going back and opening another share, Dolphin reads the perms from the "NameOfTheShare" UDSEntry. Prior to applying my partial fix, the perms were set to 555 and the root of the share was read-only. - The same behavior applies to any other shares provided by the server. The only share that will appear as writable is the share that was accessed first. I cooked up two patches that should get kio_smb more in line with the KIO framework expectations. - The "." UDSEntry is now always created. If the directory does not have a parent (server, workgroup) the UDSEntry is created with read-only permissions. Otherwise the correct permissions are fetched through libsmbclient. - There is a (a bit kludgy) fix for a case where kio_smb signals both finished() and error() to KIO. With these two patches in place on top of the previous patch KIO no longer complains about kio_smb's misbehavior and Dolphin behaves in a sensible way when browsing Samba shares. As far as I could test it works fine for me with no complains from KIO in the logs.
Created attachment 106547 [details] Patch 1, makes sure that the root UDSEntry gets created.
Created attachment 106548 [details] Patch 2, do not call finished() after error() has been called
Great! If its stable, when could we expect it to make its way into KDE?
You should upload those patches to phabricator.kde.org They will get lost otherwise.
(In reply to Jakub Gocoł from comment #60) > You should upload those patches to phabricator.kde.org > They will get lost otherwise. I am aware of this. You can follow the progress of the patches here: https://phabricator.kde.org/D5947 https://phabricator.kde.org/D6616 https://phabricator.kde.org/D6617
Git commit 2574c9158febdcb3dd7a0ebc3e76311f016d00d0 by Elvis Angelaccio, on behalf of Michal Malý. Committed on 12/07/2017 at 09:55. Pushed by elvisangelaccio into branch 'master'. Always create the "." UDSEntry Summary: The smb_kio plugin does not create the "." UDSEntry, relying on the underlying KIO infrastructure to create a default one. This patch ensures that the UDSEntry is always created with proper access permissions. Reviewers: elvisangelaccio Differential Revision: https://phabricator.kde.org/D6616 M +22 -1 smb/kio_smb_browse.cpp https://commits.kde.org/kio-extras/2574c9158febdcb3dd7a0ebc3e76311f016d00d0
Git commit e792aa44b5aa0b122e006234a8f87a16ff12fe6f by Elvis Angelaccio, on behalf of Michal Malý. Committed on 12/07/2017 at 09:57. Pushed by elvisangelaccio into branch 'master'. Return appropriate error code from browse_stat_path() instead of trying to deal with the error internally. Summary: Current behavior of browse_stat_path() can result in both finished() and error() being signaled to KIO. This patch adjusts the logic to prevent this case. Reviewers: elvisangelaccio FIXED-IN: 17.08.0 Differential Revision: https://phabricator.kde.org/D6617 M +2 -3 smb/kio_smb.h M +38 -29 smb/kio_smb_browse.cpp https://commits.kde.org/kio-extras/e792aa44b5aa0b122e006234a8f87a16ff12fe6f
Thx for your efforts. Does this also fix the behavior that e.g. a large video file needs to get completely copied to the client system first before it can be watched when it is opened e.g. via Dolphin on a Samba share? This is an important usebase, since many people store their videos on their NAS in a local network and the current behavior is really, really inconvenient.
(In reply to tempel.julian from comment #64) > Thx for your efforts. > > Does this also fix the behavior that e.g. a large video file needs to get > completely copied to the client system first before it can be watched when > it is opened e.g. via Dolphin on a Samba share? No, and that's likely not going to happen any time soon (no one is working on it).
*** Bug 382271 has been marked as a duplicate of this bug. ***
(In reply to tempel.julian from comment #64) > Thx for your efforts. > > Does this also fix the behavior that e.g. a large video file needs to get > completely copied to the client system first before it can be watched when > it is opened e.g. via Dolphin on a Samba share? > This is an important usebase, since many people store their videos on their > NAS in a local network and the current behavior is really, really > inconvenient. Every KIO slave needs to create a local copy of the remote file - this is how KIO is designed. You can always mount a remote SMB share with CIFS if you really need to work with it as if it were a local file system.
Playing videos on Samba shares not working seems to be tracked by https://bugs.kde.org/show_bug.cgi?id=355328. Is it actually working now, but just slow due to the need to download a full copy first?
*** Bug 384666 has been marked as a duplicate of this bug. ***