Red Hat Bugzilla – Bug 920536
gvfs (libsmbclient) can't read file from Samba 3.0.32 server
Last modified: 2014-06-24 02:43:57 EDT
Created attachment 708892 [details]
Error message when I try copy the file from netowrk share to loacl drive
Description of problem:
I can mount a samba share on IOMEGA home media network hard drive (hostname: hmnhd-ti1kls) from nautilus. I can browse through the directories. If I try copy a file to a local directory (or to another samba share), it fails with the message "Software caused connection abort". If I try to open a file on the samba share, the file fails to open. If I open a text file, gedit gives the same error, "Software caused connection abort". I can copy files to the share and create directories with no problem.
If I mount through the command line / fstab, the connection works perfectly. I can copy to / from and read the files
I can mount a samba share hosted on a fedora 17 laptop (x64) through nautilus, and all works well. I can copy from the share and open files on the share.
Version-Release number of selected component (if applicable):
Every time I connect through nautilus
Steps to Reproduce:
2.Click on Browse Network
3.Open the "hmnhd-ti1kls" device
4.Open the shared folder
5.Try copy a file to local hard drive
6.Get message "Software caused connection abort"
7.Try open a text file.
8.Gedit (very!) briefly flashes up content of file and then gives error message "Software caused connection abort"
Unable to open/copy files
Can copy files to local machine, or read files on samba share
Thanks for reporting a issue. Please provide a network trace for further investigation.
Can you reproduce the problem with the smbclient commandline tool from the samba-clients package?
Created attachment 709126 [details]
Wireshark trace of trying to copy file from network share
When I use the smbclient commandline tool, I can transfer files to the local machine with no errors. Attached wireshark capture of trying to copy file via nautilus.
Created attachment 709127 [details]
Wireshark Trace while copying file via nautilus
When I use the smbclient commandline tool, I can transfer files to the local machine with no errors. Attached wireshark capture of trying to copy file via nautilus. The file failed to copy normally.
When copying files, the error always occurs towards the end of the copy process. This is especially evident on large files.
Ok, so everything works using smbclient.
(Can you create a capture?)
Can you reproduce it using the smbget commandline tool?
(Can you create a capture?)
You can also upload captures to http://cloudshark.org/ and paste the url here.
This could be related to https://bugzilla.samba.org/show_bug.cgi?id=9706
Actually looking at this closely it doesn't look related to Samba bug #9706.
What is strange about this is the client it requesting a 64512 byte read (which is ok), and once it gets the 34441 byte reply it then asks for a further 30071 bytes at offset 34441 (it's trying to get the rest of the file after a short read), but when the server then returns a zero byte reply (packet 201) it should finish.
Instead it continues and issues another 1022 byte read, which is completely incorrect and the server quite naturally returns ACCESS_DENIED.
Actually this looks like:
especially the code that was before:
git show 24309bdb2efca36375f3c833f72ebec3908d31fd
but that was fixed in Samba 3.4.x days. Can you get a debug level 10 log from the client side ? I would dearly love to see how nautilus is driving the library here.
Andreas, can you look at how the nautilus code is driving cli_read() ?
The reply from the readX that returns 0 and the readX request for the next 1022 bytes are very close together, time-wise. I really want to know where that 1022 byte request is coming from - libsmbclient or nautilus ?
I copied a file from the network share using smbclient and smbget. Both times the file copied successfully. I uploaded the captures to cloudshark. I copied the same file, using nautilus to mount the share, again and included that trace. The captures are at the following locations:
The smbclient Trace is at http://cloudshark.org/captures/edc925493d9a
The smbget Trace is at http://cloudshark.org/captures/d5ef5ff54c60
The 2nd Nautilus Trace is at http://cloudshark.org/captures/3ad3ce05a027
I added the lines
debug level = 10
debug pid = true
max log size = 0
to smb.conf and I can upload the log.nmbd and log.smbd if it will help.
Again, when I copy files from a samba share hosted on Fedora 17, there is no problem. The problem is when I copy a file from the Iomega network drive (I'm not too sure if it is a samba share). When I was running Fedora 17 on my pc, there was no problems coping from the Iomega network drive.
The fstab entry for the network share looks as follows:
//192.168.1.111/backups /mnt/backup/ cifs rw,soft,username=user,password=pass,domain=mshome
I can access the shares at /mnt/backup/ without any problem. The problem seems to occur when nautilus is used to mount the share.
Oh, you mounted the share with cifs. Then his is not a Samba bug but a cifs kernel bug and belongs to Jeff :)
Jeff, in the first capture if you look at packet #177 you can see that the file size is 34441. In packet #180 we request to read 64512 bytes. Packet #197 returns 34441 bytes (so the complete file). In packet #202 we try to read 1022 bytes at offset 64512, but we already read the complete file. So we get an error in packet #203.
The cifs mount works normally. Is it the gvfs mount through nautilus that is the problem?
(In reply to comment #12)
> The cifs mount works normally. Is it the gvfs mount through nautilus that is
> the problem?
Right. As far as I can tell, the capture in comment #3 is using libsmbclient in some fashion:
Native OS: Unix
Native LAN Manager: Samba
...those labels would be different if this were the cifs.ko client. Liam also mentioned in comment #10 that when he mounts with cifs that this works fine. Reassigning back to samba.
The error response in frame 203 is odd though. In frame 199, the client tries to read starting just at the EOF and gets back STATUS_SUCCESS but 0 bytes...fine.
Then it tries to read way past the EOF:
202 12.604426000 192.168.1.107 192.168.1.111 SMB Read AndX Request, FID: 0x2dfa, 1022 bytes at offset 64512
203 12.611132000 192.168.1.111 192.168.1.107 SMB Read AndX Response, FID: 0x2dfa, Error: STATUS_ACCESS_DENIED
...and gets back ACCESS_DENIED? Shouldn't that be returning another STATUS_SUCCESS and 0 bytes?
There is a bug with gvfs and glib2 headers which could be the problem, see:
gvfs and 'smbget' both use libsmbclient and 'smbget' works.
Liam: Could you please try if it works with:
I installed samba-4.0.4-3, and tried to copy/read a file but I still got the same error. I could not open the file through nautilus, and there was an error if I tried to copy the file to the local drive from the network share.
Liam: Please get me a full level 10 debug log of the failing copy/read operation with nautilus. You can enable debug logging in gvfs with:
GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r
That's the gvfs read function.
do_read (GVfsBackend *backend,
GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend);
/* libsmbclient limits blocksize to (64*1024)-2 for Windows servers,
* let's do the same here to achieve reasonable performance. (#588391)
* TODO: port to pull mechanism (#592468)
if (bytes_requested > 65534)
bytes_requested = 65534;
smbc_read = smbc_getFunctionRead (op_backend->smb_context);
res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, buffer, bytes_requested);
if (res == -1)
g_vfs_job_failed_from_errno (G_VFS_JOB (job), errno);
g_vfs_job_read_set_size (job, res);
g_vfs_job_succeeded (G_VFS_JOB (job));
Liam: Better use
GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r
I think I understand what is going on here.
We need a code change inside source3/libsmb/clireadwrite.c to ignore NT_STATUS_ACCESS_DENIED errors once we've gotten a zero length read (EOF) return.
Let me look at a patch for this..
Ok, before I work on this I really want to see the debug level 10 log from the server.
Even on 3.0.x a read beyond end-of-file should still return zero bytes, not an ACCESS_DENIED error.
Created attachment 717866 [details]
GVFS log file while copying file mounted under Nautilus
I mounted a network share (hosted on the IOMEGA Home Media NetworK HD) using nautilus. I tried copying a file (Yum Updates.odt) to the local drive, overwriting the existing file. The file failed to copy. Attached is the results of 'GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r > gvfs-log.txt'
I booted my PC from a F17 liveUSB. I mounted the network share hosted on the IOMEGA drive. I copied a file from the share to the local drive. It copied across with no error. The Wireshark trace is at: http://cloudshark.org/captures/fdcd898c6030
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.
I've got this problem on Fedora 20. But it turns out not to be a bug in the NAS ("IOmega Home Media Network Hard Drive, Cloud Edition").
The best information on this problem, and some work-arounds, is https://bugzilla.samba.org/show_bug.cgi?id=10584