Need a network file system with Windows client and freeBSD server

[Andrew L. Gould]

On Wednesday 14 July 2004 11:26 am, Bill Moran wrote:
> "Artem Kuchin" <matrix at itlegion.ru> 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