Re: Need a network file system with Windows client and freeBSD server

From: Andrew L. Gould (algould_at_datawok.com)
Date: 07/14/04

  • Next message: Jerry McAllister: "Re: I downloaded everything to no avail! ISO's fail to burn" 
    To: freebsd-questions@freebsd.org
Date: Wed, 14 Jul 2004 11:55:45 -0500

    On Wednesday 14 July 2004 11:26 am, Bill Moran wrote:
    > "Artem Kuchin" <matrix@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
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Jerry McAllister: "Re: I downloaded everything to no avail! ISO's fail to burn"

    Relevant Pages

    • RE: Controlling access to drive C and IE settings
      ... I suggest you refer to the following article to use the policy below to ... restrict local drives. ... Locking Down Windows Server 2003 Terminal Server Sessions ...
      (microsoft.public.win2000.group_policy)
    • Re: Terminal Server Drive Mapping
      ... >I guess you are running W2K on the Terminal Server? ... >You'll need an add-on like Citrix, or upgrade to Windows ... >> have enabled Disk Drives. ...
      (microsoft.public.win2000.termserv.clients)
    • Re: Volume Serial Number
      ... AFAIK This isn't supported by windows terminal server. ... you see my intention was to select the "Disk Drives" option on the RDP ...
      (microsoft.public.windows.terminal_services)
    • Re: Need a network file system with Windows client and freeBSD server
      ... You expect people to be able to work on mapped drives ... Windows is not used to high-latency links for file- ... You'll probably have better results setting up some sort of terminal serer ... (either VNC or MS terminal server) ...
      (freebsd-questions)
    • Make the Most of Your New PC
      ... mint Windows Vista computer this holiday ... the Workgroup name is exactly the same for all the computers in the ... that doesn't support USB 2.0) and low-capacity portable hard drives. ...
      (microsoft.public.windows.vista.general)
    • Quantcast