From owner-freebsd-questions@FreeBSD.ORG Wed Nov 19 18:56:20 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 429011065677 for ; Wed, 19 Nov 2008 18:56:20 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.244]) by mx1.freebsd.org (Postfix) with ESMTP id D4E2D8FC13 for ; Wed, 19 Nov 2008 18:56:19 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: by hs-out-0708.google.com with SMTP id 54so60441hsz.11 for ; Wed, 19 Nov 2008 10:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=quJUftMV3TtyPJRVMBHP586ISsMwn9RAdNmAPgyIYDM=; b=JsbZj3bojnF2mZwR+IFibGQ1B0HAmfcvDYR3sIcVpOoCV8+O0QIC3xoO3avvatDTjI 1/m7mz9bJCyONBAeM3SzyIumCE0tj9lMcHYSs+oRiwRK3l5xZQwVSDKDE4YMAP5mkWeH of6mOSjG9r1bdpJeskYEueSujXk+2xyJ6yQz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Zh83qcRHpjEMGnd6gzYBgNiY1fEND3A9DOlndP4+r4G0O1Ppfxsf3jLRzlsH8bpgW7 bPjZjMCYhaNbd7DSOYeFUe9bqAHKV7YRSHtnvztl08DI0mmZitXJR6umyZr5KUET7dLQ BPYgz9SA+pLIcDkHmfBABYe6HddDXZakOeTyE= Received: by 10.150.50.1 with SMTP id x1mr2526433ybx.249.1227120977414; Wed, 19 Nov 2008 10:56:17 -0800 (PST) Received: by 10.150.144.19 with HTTP; Wed, 19 Nov 2008 10:56:17 -0800 (PST) Message-ID: <25ff90d60811191056pba65cbatf4c7ad693f70f28@mail.gmail.com> Date: Wed, 19 Nov 2008 13:56:17 -0500 From: "David Horn" To: "Derek Ragona" In-Reply-To: <6.0.0.22.2.20081119062849.02693de0@mail.computinginnovations.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> 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 18:56:20 -0000 On Wed, Nov 19, 2008 at 7:37 AM, Derek Ragona wrote: > 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. 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.