GNOME Bugzilla – Bug 779123
Copy files does not work for cifs mounts
Last modified: 2018-05-24 19:24:45 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
and the nautilus version was the same with both kernels? can you try to copy with gvfs-copy in the terminal?
Created attachment 346549 [details] strace output of gvfs-copy
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.
cool, thanks for the debugging, that should be enough. Moving to gvfs to decide whether is the kernel's fault.
(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://?
(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).
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 https://bugzilla.samba.org/ under CifsVFS product and let us know the bug number.
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?
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.: https://git.gnome.org/browse/glib/tree/gio/gfile.c#n3213 Consequently, the following while never ends, because n_written is 0 and n_read is 677 in your case: https://git.gnome.org/browse/glib/tree/gio/gfile.c#n2956 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...
-- 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: https://gitlab.gnome.org/GNOME/glib/issues/1246.