Bug 414482 - Dolphin can't create on network resources
Summary: Dolphin can't create on network resources
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: Samba (show other bugs)
Version: 19.12
Platform: Other Linux
: HI major
Target Milestone: ---
Assignee: Plasma Bugs List
Keywords: regression
: 375553 (view as bug list)
Depends on:
Reported: 2019-11-25 06:36 UTC by hopyres
Modified: 2020-02-16 17:13 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 19.12.3

Permissions tab (129.21 KB, image/png)
2020-02-12 16:01 UTC, Nate Graham
Share tab (114.69 KB, image/png)
2020-02-12 16:02 UTC, Nate Graham
Mount network resources (891.96 KB, image/png)
2020-02-13 05:56 UTC, hopyres

Note You need to log in before you can comment on or make changes to this bug.
Description hopyres 2019-11-25 06:36:23 UTC
File manager Dolphin can't create on network resources: file, folder and etc, this is create only locally.
Comment 1 Elvis Angelaccio 2019-11-25 20:56:35 UTC
What kinf of network resources? ftp? sftp? webdav?
Comment 2 Bug Janitor Service 2019-12-10 04:33:10 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Bug Janitor Service 2019-12-25 04:33:09 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:

Thank you for helping us make KDE software even better for everyone!
Comment 4 hopyres 2019-12-25 05:33:37 UTC
Dolphin version 19.12.0  can't create folder and copy file.
Comment 5 hopyres 2019-12-25 05:36:32 UTC
(In reply to hopyres from comment #4)
> Dolphin version 19.12.0  can't create folder and copy file.

This operation can't on SMB resources.
Comment 6 Nate Graham 2019-12-26 20:20:27 UTC
I can confirm this issue with my Samba share. Can't create, can't paste.
Comment 7 Nate Graham 2019-12-26 20:21:35 UTC
*** Bug 375553 has been marked as a duplicate of this bug. ***
Comment 8 Harald Sitter 2020-02-10 12:42:07 UTC
Can you confirm that the new directory actually is writable by your user on the server?
I have definitely seen samba create directories with nobody:nogroup ownership when folders are created through the samba guest account. There's not much we can do about this client-side though, if the permissions are incorrect server-side the directory isn't writable to us which would explain why pasting doesn't work. In bug #375553 there's also talk of the paste action itself being greyed out, which I think also would only happen if the directory is detected non-writable.
Comment 9 Nate Graham 2020-02-11 20:38:07 UTC
Yes, the shared location is writable by the local user on the server.

The server is a Windows 10 PC in my loving room. I access it from Dolphin via smb://gaston@living-room-pc/Users/gaston/Desktop/.

If I log in as the user "gaston" on the machine locally, I can create files and folders on the desktop.

I'd be happy to provide any logging and perform whatever troubleshooting steps you can think of.
Comment 10 hopyres 2020-02-12 05:08:44 UTC
On shared network resources in Dolphin file manager is locked menu "Create ..."
Comment 11 Nate Graham 2020-02-12 05:15:47 UTC
(In reply to Nate Graham from comment #9)
> The server is a Windows 10 PC in my loving room
Most embarrassing typo of the year award goes to me lol
Comment 12 Harald Sitter 2020-02-12 14:09:58 UTC
Oy vey, windows is tricky -.-

First question I guess is does it work with smbclient?

> smbclient -U gaston '\\living-room-pc\Users\gaston\Desktop'

`ls` should show dir content, `mkdir foo` should make a new directory etc.

If that is the case I guess the following won't be necessary since it's likely some weird bug in the slave. If it doesn't work with smbclient then I need server side logs. As a simple prelude though..on the server:

- Win+R -> C:\Users\gaston (I am guessing)
- explorer opens
- right click Desktop
- Security tab
- click Advanced button
- new dialog with 4 tabs should open
- take screenshots of the tabs: Permissions, Share
Comment 13 Nate Graham 2020-02-12 16:01:30 UTC
as discussed in chat, using smbclient fails for unknown, irritating reasons. Will attach the requested screenshots.
Comment 14 Nate Graham 2020-02-12 16:01:59 UTC
Created attachment 125905 [details]
Permissions tab
Comment 15 Nate Graham 2020-02-12 16:02:12 UTC
Created attachment 125906 [details]
Share tab
Comment 16 Harald Sitter 2020-02-12 17:52:53 UTC
We've done some extra debugging on IRC.

The permissions seen on the screenshot look entirely correct. Furthermore simply calling mkdir in smbclient actually works. So, the directory is technically writable.

As it turns out we detect the permissions as readonly though.

I believe this is because IS_DOS_READONLY is true https://github.com/samba-team/samba/blob/8b04590e4d8f817ad6d194bb9d622c18734e3011/source3/libsmb/libsmb_stat.c#L58 or rather I expect it must be because that code doesn't really have any other way to create a readonly mode set.

Fortunately this is indeed easy to reproduce by simply sharing the **Desktop** of a windows10 system. I does however seem to not make a difference if one shares it via the wizard (which would share Users as far as I can tell) or the Desktop dir directly under a Desktop share. I further suspect that the readonlyness on our end may have to do with the default state that the Desktop dir is marked partially readonly in the ntfs attributes by default.

So, the problem could either be in libsmbc collapsing readonly states incorrectly, or the server saying something is readonly when it isn't. The latter would make this a rather awkward problem to solve as the only recourse would likely be to ignore mode flags entirely. Which isn't the biggest loss I guess since the mode set is so very minimal anyway. It does however also mean that we'd not correctly detect when something is truly readonly.

It may be that the new api mentioned in bug #402988 helps us get a better graps of the readonly state though.

This needs a bunch more of what goes on between libsmbc and the server.
Comment 17 Harald Sitter 2020-02-12 17:55:27 UTC
Oh, and FTR, it looks like gvfs simply ignores the mode and claims it doesn't know the permissions. Which I suppose makes sense given we can't model ntfs permissions as regular unix modes anyway.
Comment 18 Nate Graham 2020-02-12 17:57:51 UTC
If worse comes to worse, I guess we could do that too, yeah.
Comment 19 hopyres 2020-02-13 05:56:42 UTC
Created attachment 125931 [details]
Mount network resources

Screenshot with Dolphine locked menu "Create ..."
Comment 20 Harald Sitter 2020-02-14 16:03:11 UTC
Git commit 718abcb69b78385123dd7a05a66a656af772d581 by Harald Sitter.
Committed on 14/02/2020 at 14:58.
Pushed by sitter into branch 'master'.

smb: disable mode bits getting forwarded to KIO

mode bits in libsmb_stat are fairly cheaply constructed. file and directory
qualification is alright, beyond that it is a bit of a shambles.
specifically +W is set iff the DOS attribute READONLY isn't set, but
that attribute doesn't mean what we think it means, at least not on
NT+ systems. see exhaustive comment.

long story short: we cannot represent mode bits accurately because NT's
access controls simply do not map to posix mode bits. therefore I'm
removing the mode setting for the udsentry, making all entries effectively

whether an entry truly is writable is hard to say anyway. specifically
because SMB+NTFS have independent ACLs. so, the SMB ACL may allow a
given user or group to do something, that doesn't mean they'll also
have permissions on a file system level.
FIXED-IN: 19.12.3

Test Plan:
previously not writable shares as described in the bug report are now writable.
permission dialog looks a bit meh now, it wasn't really designed around not knowing
what the access situation is. gnome simply shows a "dunno what permissions we have" label
instead of everything, that seems like a reasonable approach

Reviewers: ngraham

Reviewed By: ngraham

Subscribers: dfaure, kde-frameworks-devel, kfm-devel

Tags: #dolphin, #frameworks

Differential Revision: https://phabricator.kde.org/D27372

M  +25   -4    smb/kio_smb_browse.cpp

Comment 21 Nate Graham 2020-02-16 17:13:09 UTC
See Bug 417749.