Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Nov 2008 13:56:17 -0500
From:      "David Horn" <dhorn2000@gmail.com>
To:        "Derek Ragona" <derek@computinginnovations.com>
Cc:        FreeBSD-questions@freebsd.org
Subject:   Re: smbfs 2 GB file size limit
Message-ID:  <25ff90d60811191056pba65cbatf4c7ad693f70f28@mail.gmail.com>
In-Reply-To: <6.0.0.22.2.20081119062849.02693de0@mail.computinginnovations.com>
References:  <6.0.0.22.2.20081117193403.025dfa50@mail.computinginnovations.com> <25ff90d60811172223t226714aq6e8202b19a2c8bfb@mail.gmail.com> <6.0.0.22.2.20081118055913.026155c0@mail.computinginnovations.com> <25ff90d60811181050w48d78914m5911bc1c04f4552@mail.gmail.com> <6.0.0.22.2.20081119062849.02693de0@mail.computinginnovations.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 19, 2008 at 7:37 AM, Derek Ragona
<derek@computinginnovations.com> wrote:
> At 12:50 PM 11/18/2008, David Horn wrote:
>
> On Tue, Nov 18, 2008 at 7:06 AM, Derek Ragona
> <derek@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@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.

You may want to just do single variable tests to determine for certain
if you are having a problem with scp or with smb.

- First test:        cp >2GB file directly from the FreeBSD local disk
file system to a mounted smbfs file system
- Second test:   scp >2GB file from remote (other server) to FreeBSD local disk

Once you figure out which one is the problem, you can try changing
variables within that scope.

For example, if the issue seems to be scp, try using sftp (both use
ssh transport). You could also try updating ssh on both machines.  If
you are running OpenSSH prior to 4.4 on any machine, there was a known
bug with scp and large files that only affects some platforms. (ssh -v
will show your version)

See ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog
under 20060318

If the problem seems to be smbfs, then try a smbclient test.

That's about all I can think of at the moment.

Good Luck.

--_Dave

>
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25ff90d60811191056pba65cbatf4c7ad693f70f28>