Bug 454693

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