smbfs 2 GB file size limit
Derek Ragona
derek at computinginnovations.com
Sat Nov 22 10:47:46 PST 2008
At 09:21 AM 11/20/2008, David Horn wrote:
>On Thu, Nov 20, 2008 at 7:07 AM, Derek Ragona
><derek at 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 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.
> >
> >>
> >> 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.
>
>This does not really tell us much other than scp can work with large
>files (which we knew)
>
>What ssh version is running on both of these "other" systems ?
>What OS are both of these other systems ?
>
> >
> > So it looks to me like there is some issue with the scp that is within
> > FreeBSD i386 7.
> >
>
>As per my previous message, I still suggest running single variable
>tests to make sure that you know what is causing the failure, but if
>you just want to jump to a possible solution, you can try updating ssh
>to the latest in the ports tree (5.0p1).
>
>If you have the FreeBSD ports collection installed and updated using
>portsnap(8) or csup(1) , just do:
>
>cd /usr/ports/security/openssh-portable
>make install
>
>Otherwise, install / update your ports collection using portsnap(8)
>(fetch update or fetch extract) first, then install openssh-portable.
>
>Good Luck.
>
>---Dave
Dave,
I repeated my scp test it was still broken.
So I installed the port, and had the same broken result. Interestingly
though, I can watch the scp write a file bigger than the 2GB while doing
the copy. But once the copy is done the file is truncated to 2GB. I saw
this with both the base scp and the port. If I cp the 32GB file from one
location to another all on the same network share, it all gets copied. So
there is some bug in scp when it finishes a copy.
-Derek
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the freebsd-questions
mailing list