From owner-freebsd-questions@FreeBSD.ORG Wed Nov 19 12:37:30 2008 Return-Path: Delivered-To: FreeBSD-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F4B1065679 for ; Wed, 19 Nov 2008 12:37:30 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id 681D48FC18 for ; Wed, 19 Nov 2008 12:37:28 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.14.2) with ESMTP id mAJCbQDH020398; Wed, 19 Nov 2008 06:37:27 -0600 (CST) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20081119062849.02693de0@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 19 Nov 2008 06:37:12 -0600 To: "David Horn" From: Derek Ragona 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> Mime-Version: 1.0 X-Antivirus: avast! (VPS 081118-0, 11/18/2008), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV 0.94-exp/8650/Tue Nov 18 22:59:50 2008 on betty.computinginnovations.com X-Virus-Status: Clean X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: mAJCbQDH020398 X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-questions@freebsd.org Subject: Re: smbfs 2 GB file size limit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 12:37:30 -0000 At 12:50 PM 11/18/2008, David Horn wrote: >On Tue, Nov 18, 2008 at 7:06 AM, Derek Ragona > wrote: > > At 12:23 AM 11/18/2008, David Horn wrote: > > > > On Mon, Nov 17, 2008 at 8:36 PM, Derek Ragona > > 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.