smbfs 2 GB file size limit

[Derek Ragona]

At 12:50 PM 11/18/2008, David Horn wrote:
>On Tue, Nov 18, 2008 at 7:06 AM, Derek Ragona
><derek at computinginnovations.com> wrote:
> > At 12:23 AM 11/18/2008, David Horn wrote:
> >
> > On Mon, Nov 17, 2008 at 8:36 PM, Derek Ragona
> > <derek at computinginnovations.com> wrote:
> >> I have FreeBSD 7.0 Release and if I mount_smbfs  a network NTFS share I
> >> have
> >> a 2 GB size limit on files.  I checked the handbook and list archives but
> >> have not found a solution.
> >
> > I just ran a quick test, and was not able to reproduce this issue with
> > the mount_smbfs from FreeBSD 7.0.  I tried against a Windows 2003
> > Server SP2, Windows XP SP3, and Samba 3.0 {on FreeBSD 7} with a 3.5GB
> > file.
> >
> > Was your issue with reading from or writing to a SMB share ?
> >
> > It was writing to a smb share.
> >
> >
> > What is the server software and OS version ?
> > (if Microsoft Windows, please include Service Pack number as well, as
> > it might make a difference)
> >
> > Windows 2003 server 32bit.
> >
> > How much disk space is left on your server volume ?
> >
> > Over a terabyte free
> >
> > Are there disk quotas enabled on the server ?
> >
> > None
> >
> > What error message are you getting from your FreeBSD client (if any) ?
> >
> > No error message, it just stopped writing at 1 Gb.  I was doing this using
> > scp.
>
>Whoa, hopefully you just made a few typos here, or we are going down
>the wrong path of investigation.
>
>Did you really mean to say scp or cp ?
>      scp(1)                   - secure copy (remote file copy program)
>      cp(1)                    - copy files
>
>If you really meant scp, then the problem is not mount_smbfs, but
>instead likely a buggy scp client or server (which does not use smb
>for transport, but ssh)
>
>What is the exact byte count that your write stops at ?  You
>originally stated 2GB, then 1GB.

This problem occurs under the following scenario:

I have a windows share mounted on a FreeBSD 7.0 release (i386) using 
mount_smbfs.

I was trying to scp from another server on the LAN to this share a 30GB 
file.  The scp only copied 2 GB of that 30 GB file.   This was using the 
scp on FreeBSD 7.0.

I will try another scp application to determine if it is the scp, or 
mount_smbfs.

I know the server I was coping from via SCP is not an issue.  I was able to 
transfer that 30 GB file from that source server to another *nix server on 
the LAN.



> >
> > Can you check the smb server logs and see if you are getting any error
> > messages there ?
> >
> > Well I'm just mounting the volume to FreeBSD from the Windows server so not
> > sure I'll find much in the logs besides the system log, but I will look.
> >
> > You may want to get a Wireshark trace and see if you can capture the
> > SMB error message/error code.
> >
> > I have heard of people running into similar problems when running
> > against older server software (NT 4.0/old samba) when the SMB session
> > did not negotiate large file/large write support (a function of the
> > SMB server capabilities session negotiation)
> >
> > I saw posts to that effect and that you needed samba 3.x to support large
> > files sizes, and the lfs option.  But the mount_smbfs doesn't offer any
> > large file option.
> >
>
>Only bother with this next bit if you are morbidly curious as to how
>things work rather than just want to solve your problem, as it gets
>into the nitty gritty details of smb:
>
>mount_smbfs will allow for lfs (CAP_LARGE_FILE) automatically by
>specifying it's dialect capabilities in the smb negotiation.
>
>If you umount your smb share, then start a tcpdump you can capture the
>smb negotiation "Capabilities" bitmask to see if CAP_LARGE_FILE is
>being negotiated - the server specifies this capability.  The client
>just sends the dialects of smb supported.    For example:
>
>tcpdump -vvv -s 1500 -i em0 host server.example.com | grep Capabilities
>
>{  where em0 is the network interface in use on FreeBSD and
>server.example.com is the hostname/ip address of your smb server  }
>
>Then do a mount of the smb share (while tcpdump is running) and you
>should capture the Capabilities negotiated.
>
>For example:
>
>Capabilities=0x1F3FD
>
>If you decode the bitmask by using this reference :
>http://msdn.microsoft.com/en-us/library/aa302230.aspx {hint:  only
>look at the last four bytes of the Capabilities line (e.g. F3FD in my
>example)} Or if you have kernel source installed, you can look in
>/usr/src/sys/netsmb/smb.h for the details.
>
>    - Capabilities: 0x0001F3FD
>       RawMode:            (...............................1) Supports
>SMB_COM_READ_RAW and SMB_COM_WRITE_RAW (CAP_RAW_MODE)
>       MpxMode:            (..............................0.) No
>Support for SMB_COM_READ_MPX or SMB_COM_WRITE_MPX (CAP_MPX_MODE)
>       Unicode:            (.............................1..) Supports
>Unicode Strings (CAP_UNICODE)
>       LargeFiles:         (............................1...) Supports
>large files with 64-bit offsets (CAP_LARGE_FILES)
>       NTSMBs:             (...........................1....) Supports
>SMB NTLM 0.12 dialect commands (implies CAP_NT_FIND) (CAP_NT_SMBS)
>       RPCRemoteAPIs:      (..........................1.....) Supports
>remote API requests using RPC over named pipe connections
>(CAP_RPC_REMOTE_APIS)
>       NTStatus:           (.........................1......) Can
>respond with 32-bit NT status codes in Status (CAP_NT_STATUS)
>       LevelIIOplocks:     (........................1.......) Supports
>Level II oplocks ( CAP_LEVEL_II_OPLOCKS)
>       LockAndRead:        (.......................1........) Supports
>SMB_COM_LOCK_AND_READ and SMB_COM_WRITE_AND_UNLOCK (CAP_LOCK_AND_READ)
>       NtFind:             (......................1.........) Supports
>Windows NT information level requests (SMB_QUERY_?, SMB_SET_?)
>(CAP_NT_FIND)
>       Reserved_bits10_11: (....................00..........) Reserved
>       Dfs:                (...................1............) This
>server is Distributed File System (Dfs) aware (via
>TRANS2_GET_DFS_REFERRAL) (CAP_DFS)
>       InfolevelPassthru:  (..................1.............) Supports
>Windows NT information level pass-through requests
>[SMB_INFO_PASSTHROUGH] (CAP_INFOLEVEL_PASSTHRU)
>       LargeReadx:         (.................1..............) Supports
>large read operations (CAP_LARGE_READX)
>       LargeWritex:        (................1...............) Supports
>large write operations (CAP_LARGE_WRITEX)
>       Lwio:               (...............1................) Reserved

Thanks for that info.  I will try this, as I am both curious about what the 
problem may be and interested to verify what mount_smbfs is allowing.

         -Derek 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.