File manager Dolphin can't create on network resources: file, folder and etc, this is create only locally.
What kinf of network resources? ftp? sftp? webdav?
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: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging 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!
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: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Dolphin version 19.12.0 can't create folder and copy file.
(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.
I can confirm this issue with my Samba share. Can't create, can't paste.
*** Bug 375553 has been marked as a duplicate of this bug. ***
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.
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.
On shared network resources in Dolphin file manager is locked menu "Create ..."
(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
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
as discussed in chat, using smbclient fails for unknown, irritating reasons. Will attach the requested screenshots.
Created attachment 125905 [details] Permissions tab
Created attachment 125906 [details] Share tab
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.
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.
If worse comes to worse, I guess we could do that too, yeah.
Created attachment 125931 [details] Mount network resources Screenshot with Dolphine locked menu "Create ..."
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 Summary: 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 writable. 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 https://commits.kde.org/kio-extras/718abcb69b78385123dd7a05a66a656af772d581
See Bug 417749.