SUMMARY In the following examples, the user's login name will be "username". Dolphin 24.02.0 included with Plasma 6 cannot write to a folder that has group write access and a different owner (e.g., mode 775, "root:username" ownership). This is a regression from Plasma 5 (tested with Dolphin 21.12.3 in Kubuntu). This bug prevents writing to shared folders in VirtualBox, as the shared folders have "root:vboxsf" ownership, where the user being a member of the "vboxsf" group should be able to write to the shared folders. STEPS TO REPRODUCE 1. Create a folder "testfolder" in your home directory. 2. Change the folder owner while keeping the user's default group (e.g., "sudo chown root:username testfolder"). By default, this should already be file access mode 775 where group members have write access, but change this if it is not. 3. Exit and restart Dolphin (sometimes this is necessary to trigger the bug). 4. Open "testfolder" in Dolphin and try to create or copy a file/folder to this location. OBSERVED RESULT Dolphin forbids the user from creating/copying files within "testfolder". Performing the file operations via command line is necessary to write to the folder. EXPECTED RESULT Dolphin should recognize group write access to the folder and allow the user to write to the folder. SOFTWARE/OS VERSIONS Linux: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2
*** Bug 482993 has been marked as a duplicate of this bug. ***
Yep, I am seeing this bug on Arch KDE 6.0.1 and Dolphin 24.02.0 as well. I have a folder with root:users and 775 permissions. My user belongs to the users group and yet can not write in that folder with Dolphin at all.
I can reproduce this using the steps provided so setting status to confirmed Dolphin can't create files in testfolder but the file-save dialog in kde apps does allow saving to that folder Operating System: KaOS (2024) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland
*** Bug 483313 has been marked as a duplicate of this bug. ***
This seems to be caused by https://invent.kde.org/frameworks/kio/-/merge_requests/1221
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1581
I am not sure if this was now fixed by https://invent.kde.org/frameworks/kio/-/commit/8e622280d070df7824baffd684e866c085b56f64.
At least for me this was fixed after backporting this (among other) commits.
Let's consider this fixed then. 🌠 S. Christian Collins, Benjamin Xiao, Paul Worrall, if this bug still persists while using KDE frameworks 6.1 (which will be released by us on Fri April 13, 2024 and then arrive at your door step at a point in time controlled by your distribution), we would be interested in hearing from you. Good job everyone! :)
I can confirm this bug is indeed fixed in Frameworks 6.1. Thank you!
*** Bug 485631 has been marked as a duplicate of this bug. ***
Hey, everybody. Looks like we have the same problem. It started a few months ago, after upgrading to qt6. We didn't write a bug report for a long time, because we thought that this problem would be solved quickly, as it was supposed to be common for all. So, I have the latest updated Arch Linux, kernel version 6.6.51-1-lts, Dolphin version. This workstation is an NFS client to a server that has an NFS shared directory. The folder on the server is shared in such a way that any user accessing the shared folder will work in it as a single user master (uid=1000, gid=1000). Previously it was possible to create folders and files via dolphin without problems and they were immediately assigned to the master user and master group (1000:1000). But after upgrading to qt6, something in dolphin broke. And now any users see shared folders as closed to writing. Accordingly, they can neither create folders nor files in NFS directories. At the same time all the same things can be done in any other program, in terminal for example, without problems.
Created attachment 173826 [details] problem in dolphin here is a screenshot of the problem
Created attachment 173827 [details] no problem in terminal The same folder in terminal. No problem
Here are some screenshots