Created attachment 149373 [details] Part file name. SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Load a PDF over a CIFS mounted Samba share which is working properly (I can save a modified text file using Kate to the same location without getting this error). 2. Try and save modified (highlights) PDF over itself which gives ... --- Could not open file:///media/michaelzfreeman/michaelzfreeman-home/Michael_Z_Freeman_Docs/Docs/Forge/ShipYards/Operations/Joshi Project/forty_years_of_the_law_180_the_aspirations_of_a_great_reform_its_successes_and_continuing_need.pdf. --- 3. Then the PDF is closed and Okular shows a an empty document. 4. Examining the save location shows a ".part" extension added to the end of the PDF. When this is removed the PDF opens as normal and even has the added highlights showing that it actually saved OK. OBSERVED RESULT A successfully saved PDF but with ".part" extension. EXPECTED RESULT Saved PDF with normal PDF extension. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 22.04/jammy (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Problem was tested using Flatpak installation of Okular (22.04.1) after finding problem in version 21.12.3 of Okular installed by jammy installation.
Created attachment 149374 [details] Error message
Any chance you can point us to how to create a "CIFS mounted Samba share which is working properly" so we can try to reproduce the problem? At least me i have no idea about Samba
(In reply to Albert Astals Cid from comment #2) > Any chance you can point us to how to create a "CIFS mounted Samba share > which is working properly" so we can try to reproduce the problem? > > At least me i have no idea about Samba Hi. sudo mount -t cifs //192.168.1.2/michaelzfreeman /media/michaelzfreeman/michaelzfreeman-home/ -o user=michaelzfreeman,pass=pepper73,uid=1000,gid=1000(In reply to Albert Astals Cid from comment #2) > Any chance you can point us to how to create a "CIFS mounted Samba share > which is working properly" so we can try to reproduce the problem? > > At least me i have no idea about Samba Hi. sudo mount -t cifs //192.168.1.2/michaelzfreeman /media/michaelzfreeman/michaelzfreeman-home/ -o user=michaelzfreeman,pass=pepper73,uid=1000,gid=1000
This last comment only works if i'm in your network, which i am not ^_^ I still need help setting up the server part. Also, you just put your password in the internet for everyone to read, i recommend you to change it.
(In reply to Albert Astals Cid from comment #4) > This last comment only works if i'm in your network, which i am not ^_^ I > still need help setting up the server part. > > Also, you just put your password in the internet for everyone to read, i > recommend you to change it. Eh ? There are are plenty of Samba guides out there. BTW that's not an important password. Don't worry about it.
> There are are plenty of Samba guides out there. There's also lots of C++ guides out there and I'm not asking you to learn to code.
I'm experiencing the same problem on multiple systems connected to a Samba CIFS share. Here is some relevant information (I've changed some info to anonymize usernames and IP addresses): Clients: Ubuntu 20.04, kernel 5.4.0-122-generic, Samba 4.13.17 Server: Ubuntu 22.04, kernel 5.15.0-43-generic, Samba 4.15.9 Client mount options: type cifs rw, relatime, vers=2.1, cache=strict, username=X@X, uid=1000, forceuid, gid=1000, forcegid, addr=X.X.X.X, file_mode=0755, dir_mode=0755, soft, nounix, serverino, mapposix, rsize=1048576, wsize=1048576, bsize=1048576, echo_interval=60, actimeo=1 Share options in Samba: [sharename] browseable = yes writable = yes path = /path/to/files/ write list = X@X,Y@X create mask = 700 directory mask = 700 inherit permissions = yes valid users = X@X,Y@X Saving the file on a CIFS share results in the same error as reported by Michael Freeman, but no issues with a local filesystem. Please let me know what other info is needed to troubleshoot.
(In reply to Albert Astals Cid from comment #2) > Any chance you can point us to how to create a "CIFS mounted Samba share > which is working properly" so we can try to reproduce the problem? > > At least me i have no idea about Samba Hi @albert, We have been experiencing the same issue - Here is a basic open rw share config for an ubuntu server: https://ubuntu.com/server/docs/samba-file-server To mount, use commands as per OP: sudo mount -t cifs //<server ip>/share /path/to/local/mountpoint/ -o uid=1000,gid=1000 Some further testing: - This is only an issue on samba 4, using smb protocols v[2.0 | 2.1 | 3.1.1 ] - samba 3, using smb protocol v1.0 is not affected
Further testing: Ubuntu 18.04 - Mounting samba share with ver=2.1 and using okular 17.12.3 Can edit and save file Ubuntu 20.04 - Mounting samba share with ver=2.1 and using okular 19.12.3 Fails as per bug To summarise: Okular has previously been able to edit and save files over smb protocal v2.1, and this functionality broke between 17.12.3 and 19.12.3
I've updated to Ubuntu 22.04 and Okular 21.12.3 but am having the exact same problem. The program crashes, leaving behind a "filename.pdf.part" file on the Samba share.
Cannot reproduce. See https://i.imgur.com/DLeU4GT.gif
Ah, wait you said saving modifications, not a new file, yeah that seems to fail
When opening Okular from terminal I get a... Couldn't rename "filename.pdf.part" to "filename.pdf" ( Permission denied ) The document hasn't been reloaded/swapped correctly Context: brian@Gig2Deb12:/media/test$ okular Okular-test.pdf QSocketNotifier: Can only be used with threads started with QThread kf.kio.widgets: Failed to check which JobView API is supported "The name org.kde.kuiserver was not provided by any .service files" kf.kio.workers.file: copy() QUrl("file:///tmp/okular.WxqvUE") to QUrl("file:///media/test/Okular-test.pdf") mode= -1 kf.kio.workers.file: the file doesn't have any xattr kf.kio.workers.file: Couldn't rename "/media/test/Okular-test.pdf.part" to "/media/test/Okular-test.pdf" ( Permission denied ) The document hasn't been reloaded/swapped correctly brian@Gig2Deb12:/media/test$
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1391
Git commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1 by Kevin Ottens, on behalf of Kevin Ottens. Committed on 24/08/2023 at 18:42. Pushed by ervin into branch 'master'. Don't unlink + rename on CIFS mounts during copy operations It turns out that the behavior of unlink() on CIFS mounts can be a bit "interesting". If the file one tries to unlink is opened then the operation is claimed to have succeeded but the filename is still visible in the file hierarchy until the last handle is closed. Since we rightfully attempt to copy under a temporary name + unlink + rename during copy() operations this would end badly (as the unlink() would "succeed" but the rename() would fail!). For instance Okular would constantly hit this case but it's likely not the only one to be affected. So instead we detect if the destination is a CIFS mount, in such cases we now overwrite the file directly since this actually succeed. M +7 -1 src/kioworkers/file/file_unix.cpp https://invent.kde.org/frameworks/kio/-/commit/d248949eea3e3dcbb9283f30eebcb9ae86412cd1
Git commit 3e6800b378cd143cb9c4ca4cfa500916a5e5c17c by Kevin Ottens, on behalf of Kevin Ottens. Committed on 24/08/2023 at 19:02. Pushed by ervin into branch 'kf5'. Don't unlink + rename on CIFS mounts during copy operations It turns out that the behavior of unlink() on CIFS mounts can be a bit "interesting". If the file one tries to unlink is opened then the operation is claimed to have succeeded but the filename is still visible in the file hierarchy until the last handle is closed. Since we rightfully attempt to copy under a temporary name + unlink + rename during copy() operations this would end badly (as the unlink() would "succeed" but the rename() would fail!). For instance Okular would constantly hit this case but it's likely not the only one to be affected. So instead we detect if the destination is a CIFS mount, in such cases we now overwrite the file directly since this actually succeed. (cherry picked from commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1) M +7 -1 src/ioslaves/file/file_unix.cpp https://invent.kde.org/frameworks/kio/-/commit/3e6800b378cd143cb9c4ca4cfa500916a5e5c17c