Date: Thu, 20 Nov 2008 06:07:58 -0600 From: Derek Ragona <derek@computinginnovations.com> To: "David Horn" <dhorn2000@gmail.com> Cc: FreeBSD-questions@freebsd.org Subject: Re: smbfs 2 GB file size limit Message-ID: <6.0.0.22.2.20081120060200.02635cc0@mail.computinginnovations.com> In-Reply-To: <25ff90d60811181050w48d78914m5911bc1c04f4552@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
> >
> > 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
I tried your suggestions and when I checked the capabilities I got:
# tcpdump -vvv -s 1500 -i em0 host filesrv | grep Capabilities
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 1500 bytes
Capabilities=0x1F3FD
So it looks like the share is fine, and this is probably an scp issue.
In a separate test I tried using a different scp application NOT under
FreeBSD and was able to copy the 32GB file to the this network share.
So it looks to me like there is some issue with the scp that is within
FreeBSD i386 7.
-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?6.0.0.22.2.20081120060200.02635cc0>