Ever since upgrading to the newest version of kio (kio-6.19.0-1) / kio-extras (kio-extras-25.08.2-1) pasting a file onto an SMB Share in dolphin doesn't work anymore STEPS TO REPRODUCE 1. Copy a file 2. Open the SMB Share in dolphin 3. Paste OBSERVED RESULT When pasting a file dolphin says "access denied could not write to smb" EXPECTED RESULT File gets pasted without errors Linux/KDE Plasma: EndeavourOS KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 ADDITIONAL INFORMATION Works again after downgrading kio to kio-6.18.0-1 and/or kio-extras to kio-extras-25.08.1-2 The share is hosted on a raspberrypi 5 and can be accessed when downgrading
There were no smb changes in that version of kio-extras
Experience the same issue. I could create a folder or text file, but move/copy/paste resulted in access denied errors.
I can confirm this issue on Arch Linux with KDE Frameworks 6.19. In my case, the problem also occurs when using kioclient directly, not only in Dolphin. Example command and output: $ kioclient copy -v smb://<user>@<nas>/shared-folder/test.txt smb://<user>@<nas>/shared-folder/test kioclient 6.4.5 QThreadStorage: entry 8 destroyed before end of thread 0x55e1f558dc90 QThreadStorage: entry 1 destroyed before end of thread 0x55e1f558dc90 QThreadStorage: entry 0 destroyed before end of thread 0x55e1f558dc90 No file is copied, and Dolphin shows “Access denied” when pasting to the same share. Restoring the system to Frameworks 6.18 immediately fixes the problem.
Can confirm this issue affects file moves copying and pasting files, but still lets you create text files and folders
Can confirm the issue Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.11-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
I can confirm. Create/delete still works. Additional note: Using kio-fuse and navigating the share using a terminal still allows all permitted actions as expected. Associated forum post: https://discuss.kde.org/t/kde-frameworks-6-19-with-smb-mounted-dolphin-cannot-copy-or-rename-files/40566
Did git bisect, looks like it was broken in https://invent.kde.org/frameworks/kio/-/commit/15fff1b8592648f11f20a303c8f82d61d3f19584
likely a similar issue to https://bugs.kde.org/show_bug.cgi?id=510456
A possibly relevant merge request was started @ https://invent.kde.org/network/kio-extras/-/merge_requests/473
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2022
Can confirm MR 2022 fixes this.
same here on CachyOS here my OS spec : OS: CachyOS x86_64 Kernel: 6.17.1-2-cachyos WM: kwin_wayland_wr Terminal: konsole with Synology for me, the folder are connected with "smb:[...]/[...]
*** Bug 510556 has been marked as a duplicate of this bug. ***
Exactly same bug here.
Can also confirm. Solus with Kernel 6.16.12 Plasma 6.4.5, Frameworks 6.19.0 Connecting to existing share that has been used for a long period on multiple machines. Attempted to recreate the connection and can not create new file or paste new file via Dolphin. I can open the terminal and create new file in the share. I can open a document on the share and edit contents and save successfully. But I cannot create or paste a file on the same share. I have also tested on a separate system with EndeavourOS that also has the new Framworks version, and the same issue exists.
Can confirm on Fedora 42. Last update did the same as reported.
*** Bug 510630 has been marked as a duplicate of this bug. ***
*** Bug 510635 has been marked as a duplicate of this bug. ***
Git commit bcc840654fa2af68a4942fba6f58b2955e80e7ec by Akseli Lahtinen. Committed on 15/10/2025 at 09:34. Pushed by akselmo into branch 'master'. CopyJob: Skip permission check if there is no UDS_ACCESS entry Lack of UDS_ACCESS or S_IWUSR flag in it does *not* mean that the item is definitely unwritable. The access can be indefinite until the item is actually worked with. KIO should not assume that items are unwritable, even if we lack the flag. We should just try working with the file and handle the results, not try pre-emptively decide the actions. M +12 -9 src/core/copyjob.cpp https://invent.kde.org/frameworks/kio/-/commit/bcc840654fa2af68a4942fba6f58b2955e80e7ec
*** Bug 510645 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/2024