Bug 376344 - cant write to smb shares which has write access
Summary: cant write to smb shares which has write access
Status: RESOLVED FIXED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: default (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 377126 377198 378563 382271 384666 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-02-11 11:27 UTC by Bronson
Modified: 2017-09-28 17:53 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 17.08.0


Attachments
Allow write access to root samba share (678 bytes, patch)
2017-05-22 22:14 UTC, madcatx
Details
Allow write access to root samba share (1.27 KB, patch)
2017-05-23 07:06 UTC, madcatx
Details
Patched Arch Linux PKGBUILG (2.36 KB, application/x-xz)
2017-05-23 07:08 UTC, madcatx
Details
Debugging patch (2.67 KB, patch)
2017-05-23 10:51 UTC, madcatx
Details
Patch 1, makes sure that the root UDSEntry gets created. (2.00 KB, patch)
2017-07-10 20:52 UTC, madcatx
Details
Patch 2, do not call finished() after error() has been called (3.08 KB, patch)
2017-07-10 20:52 UTC, madcatx
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bronson 2017-02-11 11:27:52 UTC
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
Comment 1 Hariec 2017-02-27 14:15:50 UTC
Absolutely the same!

Gento amd64~
KDE Plasma 5.9.2
KDE Framework 5.31.0
Qt 5.7.1
Dolphin 16.12.2
Comment 2 Diego D 2017-02-27 23:38:42 UTC
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.
Comment 3 Elvis Angelaccio 2017-02-28 11:28:09 UTC
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.
Comment 4 Elvis Angelaccio 2017-03-03 11:31:12 UTC
*** Bug 377126 has been marked as a duplicate of this bug. ***
Comment 5 mathojojo 2017-03-10 18:49:45 UTC
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
Comment 6 Elvis Angelaccio 2017-03-10 18:55:50 UTC
*** Bug 377198 has been marked as a duplicate of this bug. ***
Comment 7 Claudio Morales 2017-03-16 04:18:10 UTC
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?
Comment 8 Brett Keller 2017-04-06 18:57:57 UTC
Seeing this as well on a fresh install of KDE Neon User LTS.
Comment 9 Elvis Angelaccio 2017-04-09 09:02:43 UTC
*** Bug 378563 has been marked as a duplicate of this bug. ***
Comment 10 mathojojo 2017-04-09 10:10:28 UTC
Hello,

Just wondering... Why is this bug still in "UNCONFIRMED" Status ?? The bug has been reported here many times, and on duplicates as well...
Comment 11 fbr 2017-04-18 19:42:51 UTC
(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 :(
Comment 12 Elvis Angelaccio 2017-04-18 20:00:49 UTC
(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).
Comment 13 fbr 2017-04-18 20:18:50 UTC
(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 :)
Comment 14 tempel.julian 2017-04-23 17:02:18 UTC
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...
Comment 15 mathojojo 2017-04-23 17:26:08 UTC
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)
Comment 16 maxp779 2017-04-27 19:40:23 UTC
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.
Comment 17 Christoph Feck 2017-04-27 21:14:39 UTC
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.
Comment 18 mathojojo 2017-04-28 06:01:11 UTC
(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 !
Comment 19 Christoph Feck 2017-04-28 09:39:44 UTC
I can only speak for myself, but I only used sftp:// which is based on ssh.
Comment 20 tempel.julian 2017-05-01 16:51:39 UTC
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.
Comment 21 Martin Samek 2017-05-02 22:20:03 UTC
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.
Comment 22 Sergey 2017-05-14 18:34:47 UTC
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.
Comment 23 madcatx 2017-05-22 11:57:40 UTC
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?
Comment 24 madcatx 2017-05-22 22:13:49 UTC
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.
Comment 25 madcatx 2017-05-22 22:14:34 UTC
Created attachment 105680 [details]
Allow write access to root samba share
Comment 26 Bronson 2017-05-23 04:27:51 UTC
(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...
Comment 27 madcatx 2017-05-23 07:06:08 UTC
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.
Comment 28 madcatx 2017-05-23 07:08:20 UTC
Created attachment 105683 [details]
Patched Arch Linux PKGBUILG

Archers are welcome to try this patched PKGBUILD.
Comment 29 madcatx 2017-05-23 07:08:54 UTC
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();
Comment 30 Luca Beltrame 2017-05-23 07:23:18 UTC
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.
Comment 31 Bronson 2017-05-23 07:34:48 UTC
(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!
Comment 32 Bronson 2017-05-23 07:39:15 UTC
cant edit my last comment. Got around it with:
gpg --recv-keys 3A6A4DB839EAA6D7
Comment 33 Bronson 2017-05-23 07:46:29 UTC
ok ive ran the makepkg command(assuming this also will install the package).
Rebooted, and still have the same bug present in dolphin...
Comment 34 madcatx 2017-05-23 09:00:08 UTC
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.
Comment 35 Elvis Angelaccio 2017-05-23 10:03:39 UTC
(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.
Comment 36 madcatx 2017-05-23 10:47:53 UTC
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.
Comment 37 Christoph Feck 2017-05-23 10:51:07 UTC
> 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?
Comment 38 madcatx 2017-05-23 10:51:59 UTC
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.
Comment 39 madcatx 2017-05-23 11:10:02 UTC
(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...
Comment 40 Martin Samek 2017-05-23 12:20:49 UTC
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.
Comment 41 tempel.julian 2017-05-23 17:58:44 UTC
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.
Comment 42 madcatx 2017-05-23 19:35:42 UTC
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.
Comment 43 madcatx 2017-05-23 19:50:14 UTC
(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...
Comment 44 Luca Beltrame 2017-05-23 19:56:23 UTC
(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.
Comment 45 maxp779 2017-05-23 21:33:26 UTC
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
Comment 46 Elvis Angelaccio 2017-05-24 09:12:49 UTC
@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)
Comment 47 Sebastian Kügler 2017-05-24 10:30:09 UTC
Fixing assignee to plasma-bugs, otherwise this spams the main Plasma list and screws up filters.
Comment 48 Bronson 2017-05-24 11:09:17 UTC
(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
Comment 49 madcatx 2017-05-24 14:07:36 UTC
(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.
Comment 50 madcatx 2017-05-24 14:27:16 UTC
(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.
Comment 51 Bronson 2017-05-25 12:51:18 UTC
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")
Comment 52 madcatx 2017-05-25 22:23:11 UTC
(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.
Comment 53 Bronson 2017-05-28 06:12:44 UTC
full log here:
https://pastebin.com/H4eP8cnR

Im not sure your patch applied correclty...
Comment 54 Elvis Angelaccio 2017-07-10 17:35:12 UTC
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
Comment 55 Sergey 2017-07-10 17:51:54 UTC
Just tested this change from git. Works good. Thanks :)
Comment 56 madcatx 2017-07-10 20:51:29 UTC
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.
Comment 57 madcatx 2017-07-10 20:52:26 UTC
Created attachment 106547 [details]
Patch 1, makes sure that the root UDSEntry gets created.
Comment 58 madcatx 2017-07-10 20:52:59 UTC
Created attachment 106548 [details]
Patch 2, do not call finished() after error() has been called
Comment 59 Bronson 2017-07-11 08:26:34 UTC
Great! If its stable, when could we expect it to make its way into KDE?
Comment 60 Jakub Gocoł 2017-07-11 10:53:15 UTC
You should upload those patches to phabricator.kde.org
They will get lost otherwise.
Comment 61 madcatx 2017-07-11 11:37:56 UTC
(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
Comment 62 Elvis Angelaccio 2017-07-12 10:00:14 UTC
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
Comment 63 Elvis Angelaccio 2017-07-12 10:00:54 UTC
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
Comment 64 tempel.julian 2017-07-12 13:05:02 UTC
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.
Comment 65 Elvis Angelaccio 2017-07-12 17:32:33 UTC
(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).
Comment 66 Elvis Angelaccio 2017-07-12 17:37:41 UTC
*** Bug 382271 has been marked as a duplicate of this bug. ***
Comment 67 madcatx 2017-07-12 21:33:26 UTC
(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.
Comment 68 Nate Graham 2017-08-18 13:36:31 UTC
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?
Comment 69 Christoph Feck 2017-09-28 17:53:04 UTC
*** Bug 384666 has been marked as a duplicate of this bug. ***