Date: Wed, 19 Nov 2008 06:37:12 -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.20081119062849.02693de0@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.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.0.22.2.20081119062849.02693de0>