After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779123 - Copy files does not work for cifs mounts
Copy files does not work for cifs mounts
Product: glib
Classification: Platform
Component: gio
Other Linux
: Normal major
: ---
Assigned To: gtkdev
Depends on:
Reported: 2017-02-23 08:50 UTC by Manfred Egger
Modified: 2018-05-24 19:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Screenshot of file not beeing copied in nautilus ;-) (42.25 KB, image/png)
2017-02-23 08:50 UTC, Manfred Egger
strace output of gvfs-copy (45.47 KB, text/plain)
2017-02-23 09:52 UTC, Manfred Egger

Description Manfred Egger 2017-02-23 08:50:51 UTC
Created attachment 346539 [details]
Screenshot of file not beeing copied in nautilus ;-)

I have many cifs mounts via fstab. After upgrading to kernel 4.9, it's not possible to copy or move files from those mounts in nautilus. The copied file is created, but it never receive the contents (so the file has 0 bytes file size) and the progress indicator never finishes. If the same share is mounted via gvfs, it is working. Also if i copy the files via other tools like the terminal. The error only occurs in nautilus.

Example line from fstab:
//remote/www  /directory  cifs  credentials=.credentials,uid=1000,gid=1000,nobrl,cache=none  0 0

With kernel 4.8 (in fact latest tested and working kernel was 4.8.13) everything worked. With kernel 4.9 (tested with 4.9.6, 4.9.7, 4.9.11) the described problem occured.

Tested this on my Arch Linux machine (gnome 3.22.2) as well as the latest openSuse Tumbleweed live dvd, which has the gnome 3.22.2 and kernel 4.9.10
Comment 1 Carlos Soriano 2017-02-23 09:20:17 UTC
and the nautilus version was the same with both kernels?
can you try to copy with gvfs-copy in the terminal?
Comment 2 Manfred Egger 2017-02-23 09:52:29 UTC
Created attachment 346549 [details]
strace output of gvfs-copy
Comment 3 Manfred Egger 2017-02-23 09:53:32 UTC
Nautilus version was always the same, I only switched the kernel.

If I use gvfs-copy to copy from the mounted location, then nothing happens, which means, the copy process never finishes, just an empty file is created and I have to kill the process. Also with --progress option nothing is shown.

It also doesn't matter, if the remote share is a real Windows share, or a samba share on a Linux box.

I don't know if it helps, but when I strace gvfs-copy then it seems it runs into an endless loop:

fstat(7, {st_mode=S_IFREG|0755, st_size=677, ...}) = 0
splice(7, [0], 10, NULL, 65536, SPLICE_F_MORE) = 677
splice(8, NULL, 9, [0], 677, SPLICE_F_MORE) = 0

The last line is repeated until I kill the process. I attached the full strace output. Everything was tested using the mentioned live dvd.
Comment 4 Carlos Soriano 2017-02-23 10:00:59 UTC
cool, thanks for the debugging, that should be enough.
Moving to gvfs to decide whether is the kernel's fault.
Comment 5 Debarshi Ray 2017-02-23 10:14:43 UTC
(In reply to Carlos Soriano from comment #4)
> cool, thanks for the debugging, that should be enough.
> Moving to gvfs to decide whether is the kernel's fault.

If it is mounted via the in-kernel Samba implementation, then GVfs might not be involved at all. GVfs' Samba backend uses the user-space implementation. See:
$ ldd /usr/libexec/gvfsd-smb | grep samba
$ ldd /usr/libexec/gvfsd-smb | grep smb

To confirm, could you please check the URI schemes used by the GFiles in question? Are they file:// or smb://?
Comment 6 Manfred Egger 2017-02-23 10:32:11 UTC
(In reply to Debarshi Ray from comment #5)
> To confirm, could you please check the URI schemes used by the GFiles in
> question? Are they file:// or smb://?

I did a simple "gvfs-copy file-from-mount local-path" so in fact I guess it's file:// but I didn't add the scheme. Sorry if this was missleading, but I never used the gvfs-commands from cli.

If I use gvfs-copy smb://remote-file, then gvfs-copy complains, that the location has to mounted first. And as mentioned in my original post, if I mount the share via gvfs, everything is working as expected (no matter if the mount is done via nautilus or gvfs-mount).
Comment 7 Ondrej Holy 2017-02-23 12:28:14 UTC
GVfs isn't involved at all, generic glocalfile.c code from GLib is used in this case, but I don't think that there is anything wrong in GLib. It would be kernel/samba fault. Please file a bug on under CifsVFS product and let us know the bug number.
Comment 8 Manfred Egger 2017-02-23 13:20:39 UTC
Ok. What's a bit confusing to me is, that this error only occurs with Nautilus and gvfs-cp (as far as I could test it). With a plain cp, rsync or even with KDE's Konqueror the problem doesn't occur. I've also tested Nemo (from Cinnamon project) and the same error occurs.

I tried a few mount options and it seems, that the error only occurs with cache=none option.

Are there any other tests I could do to track down the responsible project?
Comment 9 Ondrej Holy 2017-02-23 14:05:20 UTC
Ok, you can see it with Nautilus/Nemo/gvfs-cp, because all of that uses GLib/GIO. It tries splice() before traditional read()-write(), which is the problematic part, which is not part of plain cp etc.:

Consequently, the following while never ends, because n_written is 0 and n_read is 677 in your case:

So it seems that splice() is broken somehow in recent kernel. I am not sure whether we can do something with it here... reopening, maybe somebody else will know...
Comment 10 GNOME Infrastructure Team 2018-05-24 19:24:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: