Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.nfs Subject: Re: Why not export /fs /fs/subdir? Message-ID: <1991Jun22.072758.5160@Think.COM> Date: 22 Jun 91 07:27:58 GMT References: <1991Jun18.040038.15141@Think.COM> Sender: news@Think.COM Reply-To: barmar@think.com Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 33 In article thurlow@convex.com (Robert Thurlow) writes: >> outer_handle = Lookup(mount_handle, ".."); >> bar_handle = Lookup(outer_handle, "bar"); >Sun-based server will interpret such lookups as if you'd really asked >about ".". If this is true, then that answers the original question about why you can't export /foo and /foo/bar. The server apparently treats each exported directory as if it were the root of a virtual file system. If /foo and /foo/bar were exported, /foo/bar/.. would be seen as trying to back up through that virtual root. > Have you tried this anywhere and had it give you access to >other filesystems? I'd call systems like that "broken". No, I haven't yet tried it, although I've got a good client testbed: a Symbolics Lisp Machine with NFS client support. On the Lisp Machine, the entire protocol hierarchy is directly accessible from the user mode Lisp interpreter, so I wouldn't have to reimplement anything. Maybe when I get some time I'll try it. I based my original statement on the assumption that export "access=" restrictions are only applied by the Mount daemon, not the NFS daemon (the "rw=", "anon=", and "root=" options clearly have to be implemented by the NFS daemon, though, but they are less expensive because they don't require dynamic netgroup lookups). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar