From owner-freebsd-questions@FreeBSD.ORG Wed Jul 14 16:54:40 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39F4D16A4CF for ; Wed, 14 Jul 2004 16:54:40 +0000 (GMT) Received: from asmtp-a063f31.pas.sa.earthlink.net (asmtp-a063f31.pas.sa.earthlink.net [207.217.120.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B2B043D1F for ; Wed, 14 Jul 2004 16:54:35 +0000 (GMT) (envelope-from algould@datawok.com) Received: from 20-74.lctv-b4.cablelynx.com ([24.204.20.74] helo=[192.168.63.10]) by asmtp-a063f31.pas.sa.earthlink.net with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1Bkn1e-0004i5-Dq; Wed, 14 Jul 2004 09:54:34 -0700 From: "Andrew L. Gould" To: freebsd-questions@freebsd.org Date: Wed, 14 Jul 2004 11:55:45 -0500 User-Agent: KMail/1.6.2 References: <004001c469b1$a74dacf0$0c00a8c0@artem> <002001c469bd$88400950$5e11a8c0@WINXP> <20040714122602.764c4ba3.wmoran@potentialtech.com> In-Reply-To: <20040714122602.764c4ba3.wmoran@potentialtech.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407141155.45611.algould@datawok.com> X-ELNK-Trace: ee791d459e3d6817d780f4a490ca69564776905774d2ac4b895d3aa1ae88484068e851b9ba74ce1c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.204.20.74 cc: Artem Kuchin cc: Bill Moran Subject: Re: Need a network file system with Windows client and freeBSD server X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 16:54:40 -0000 On Wednesday 14 July 2004 11:26 am, Bill Moran wrote: > "Artem Kuchin" wrote: > > > > I need sime kind of network file system which has a FreeBSD > > > > server and Windows clients (particulary Windows XP) and that > > > > FreeBSD file share must be mounted on Windows XP under a drive > > > > letter. Windows client is FAR FAR away and is behind nat. > > > > Traffic costs a lot, so that file > > > > system > > > > > > must not waste it for nothing. Of course, security is very > > > > important and security based on IP address is impossible, > > > > because client is behind > > > > nat. > > > > > > I have checked the following: > > > > So, basically you are saying that there is no solution for what i > > need? WinSCP does not suit my needs, because people on windows > > client must be able to work on files (mostly html) using different > > software and it is not just > > about moving then around, but rather editing with special editors > > and after editing they must see the result right away on the web > > server. > > In my experience, no, there is no solution to your problem. The > resason is this: > > 1) You expect people to be able to work on mapped drives (i.e. z:) > 2) You are trying to hold down the bandwidth usage > > These two goals are contradictary. You'll have to give up one or the > other (unless there's some filesystem technology out there that I'm > not familiar with) > > No matter how efficient the file-sharing protocol is, the fact that > you've got the filesystem mounted as a network drive will push tons > of extra data through the pipe. Windows is not used to high-latency > links for file- sharing, thus the performance will be noticably bad. > In my experienc, Windows users don't understand the idea of latency > either, thus they will click on something three times when they > should just wait for it to finish loading, thus generating more > bandwidth. Also, directory listings, polling for changes to > directories and all sorts of other things that Windows does with > drives will push tons of network traffic across the link, thus > driving up your costs. > > This has been my experience. Perhaps your users are smarter and more > disciplined than the people I was working with, but mounting a > network drive under windows carries a lot of traffic with it as > baggage. I've never measured exactly how much, but it's more than > most people realize. For example, I've found that a 1.5mb/sec T1 line > isn't really fast enough for a single SMB mounted drive. > > If I were you, I'd set up some sort of tunnel and run a pilot test > with 1 user. I don't expect you'll be happy with the results, but it > is possible that I didn't set things up as well as could be the last > time I did this. Just be aware of the network traffic, as it ended up > being a lot more than I expected. > > You'll probably have better results setting up some sort of terminal > serer (either VNC or MS terminal server) and allowing users to work > on the remote files that way. Terminal servers still use a lot of > bandwidth, but they're designed for slow links, so it's not quite as > bad (this may or may not be the same in your scenerio, as working > with HTML files might not generate as much traffic as the MS Access > files we were working with). This is probably very bandwidth intensive (please correct me if I'm wrong); but provides another option. I've been sharing files with relatives across the US using WebDav and SSL (on Apache2). Basically, I setup a secure web server (port 443?), blocked port 80, implemented user-password authorization in Apache2 and activated webdav on the shared folders. Authorized Windows users mount "web folders", which appear as drive letters. The use of SSL protects the username/password as well as the content in transit. Best of luck, Andrew Gould