Bug 920536 - gvfs (libsmbclient) can't read file from Samba 3.0.32 server
Summary: gvfs (libsmbclient) can't read file from Samba 3.0.32 server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: samba4
Version: 18
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-12 10:26 UTC by Liam Kinsella
Modified: 2014-06-24 06:43 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 23:05:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Error message when I try copy the file from netowrk share to loacl drive (959.49 KB, image/png)
2013-03-12 10:26 UTC, Liam Kinsella
no flags Details
Wireshark trace of trying to copy file from network share (87.91 KB, application/vnd.tcpdump.pcap)
2013-03-12 19:43 UTC, Liam Kinsella
no flags Details
Wireshark Trace while copying file via nautilus (87.91 KB, application/vnd.tcpdump.pcap)
2013-03-12 19:47 UTC, Liam Kinsella
no flags Details
GVFS log file while copying file mounted under Nautilus (46.56 KB, text/plain)
2013-03-28 22:18 UTC, Liam Kinsella
no flags Details

Description Liam Kinsella 2013-03-12 10:26:01 UTC
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):
samba-4.0.3-2.fc18.src.rpm

How reproducible:
Every time I connect through nautilus

Steps to Reproduce:
1.Open Nautilus
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"
  
Actual results:
Unable to open/copy files

Expected results:
Can copy files to local machine, or read files on samba share

Additional info:

Comment 1 Andreas Schneider 2013-03-12 18:02:35 UTC
Thanks for reporting a issue. Please provide a network trace for further investigation.

See https://www.samba.org/~asn/reporting_samba_bugs.txt


Can you reproduce the problem with the smbclient commandline tool from the samba-clients package?

Comment 2 Liam Kinsella 2013-03-12 19:43:08 UTC
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.

Comment 3 Liam Kinsella 2013-03-12 19:47:31 UTC
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.

Comment 4 Andreas Schneider 2013-03-14 15:21:08 UTC
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.

Comment 5 Andreas Schneider 2013-03-14 15:40:15 UTC
This could be related to https://bugzilla.samba.org/show_bug.cgi?id=9706

Comment 6 Jeremy Allison 2013-03-14 18:10:34 UTC
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.

Jeremy.

Comment 7 Jeremy Allison 2013-03-14 18:38:47 UTC
Actually this looks like:

https://bugzilla.samba.org/show_bug.cgi?id=6606

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.

Jeremy.

Comment 8 Jeremy Allison 2013-03-14 18:42:58 UTC
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 ?

Jeremy.

Comment 9 Liam Kinsella 2013-03-14 22:31:43 UTC
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.

Comment 10 Liam Kinsella 2013-03-14 22:42:15 UTC
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.

Comment 11 Andreas Schneider 2013-03-15 08:44:02 UTC
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.

Comment 12 Liam Kinsella 2013-03-15 09:08:24 UTC
The cifs mount works normally. Is it the gvfs mount through nautilus that is the problem?

Comment 13 Jeff Layton 2013-03-15 11:34:01 UTC
(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?

Comment 14 Andreas Schneider 2013-03-22 09:13:10 UTC
There is a bug with gvfs and glib2 headers which could be the problem, see:

https://lists.fedoraproject.org/pipermail/devel/2013-March/180302.html

gvfs and 'smbget' both use libsmbclient and 'smbget' works.

Comment 15 Andreas Schneider 2013-03-22 10:13:26 UTC
Liam: Could you please try if it works with:

https://admin.fedoraproject.org/updates/samba-4.0.4-3.fc18

Comment 16 Liam Kinsella 2013-03-22 23:25:48 UTC
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.

Comment 17 Andreas Schneider 2013-03-26 12:45:16 UTC
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

Comment 18 Andreas Schneider 2013-03-26 12:56:57 UTC
That's the gvfs read function.

static void
do_read (GVfsBackend *backend,
	 GVfsJobRead *job,
	 GVfsBackendHandle handle,
	 char *buffer,
	 gsize bytes_requested)
{
  GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend);
  ssize_t res;
  smbc_read_fn smbc_read;

  /* 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);
  else
    {
      g_vfs_job_read_set_size (job, res);
      g_vfs_job_succeeded (G_VFS_JOB (job));
    }
}

Comment 19 Andreas Schneider 2013-03-26 12:57:30 UTC
Liam: Better use

GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r

Comment 20 Jeremy Allison 2013-03-28 17:06:39 UTC
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..

Jeremy.

Comment 21 Jeremy Allison 2013-03-28 21:56:36 UTC
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.

Jeremy.

Comment 22 Liam Kinsella 2013-03-28 22:18:03 UTC
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'

Comment 23 Liam Kinsella 2013-07-22 17:13:34 UTC
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

Comment 24 Fedora End Of Life 2013-12-21 15:25:46 UTC
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.

Comment 25 Fedora End Of Life 2014-02-05 23:05:28 UTC
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 26 D. Hugh Redelmeier 2014-06-24 06:43:57 UTC
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


Note You need to log in before you can comment on or make changes to this bug.