*** UNIX MANUAL PAGE BROWSER ***

NETFS(8) System Manager's Manual NETFS(8) NAME netfs - network file system SYNOPSIS /usr/netb/setup.go DESCRIPTION The network file system is conventionally a set of directories con- tained in and a set of files and programs in Connections in the network file system are asymmetric: files on a `server' system are made acces- sible on a `client' system, usually in directory /n/server-name. Client The client runs to maintain connections; it is started by invoking from rc(8). Setup uses to control the connections to servers. Each line in friends contains six fields: network address network call argument mount point protocol id unique identifier debugging flag network calling username The network address and argument give the location of the server. They are interpreted differently according to the protocol id, which should be one of d Call the server on the named network address, with default net- work and default service name The network call argument is ig- nored. The server machine should respond by calling zarf, de- scribed below; see svcmgr(8). t Call the named network address, with default network and invoke the program named in the network call argument using the proto- col of rsh; con(1). Setup calls setlogname (see getuid(2)) to make the network call appear to have been placed by the calling username. The username may be omit- ted; is the default. The mount point is the directory on which the remote file system is to appear. The unique identifier is a integer in the range 0-255; it is used internally to distinguish connections, and must be unique among all active remote file systems (including those not maintained by setup, e.g. faced(9.5)). The debugging flag is usually 0; nonzero numbers increase the chatter in various logfiles. Setup reads the friends file when it starts, and checks for changes once a minute. Each remote file system is probed once a minute; if there is no response to several consecutive probes, the connection is torn down and restarted. Failed connections are retried every minute. Server The server program is A separate zarf process exists for each client. When a connection is started, the client sends the server a list of valid user and group names and the corresponding numerical IDs on the client system. The userid and groupid of user and group names that ex- ist on both machines are mapped so that client and server see IDs under the same names. Unmapped IDs on the server appear as -1 on the client. Client processes with unmapped IDs are denied access. Zarf is subject to access control on the server. It will have access only to files that its own userid and groupid admit. Unless run as su- per-user, it will create files with its own, not mapped, userid. Zarf reads configuration information from and The files are read only once, when zarf starts, except.local first. Usually except is the same on all machines in some administrative cluster, except.local contains things specific to a particular server system. The files contain sections beginning with the line client origin. Ori- gin is the name of the calling client, as provided by the network; matches any client. The first matching section is used. Within each section, lines have of one of the following forms. Lines beginning with are ignored. uid cname=sname Regardless of the contents of password files, map client user name cname to server user name sname. If cname is not announced as valid by the client, the line is ignored. If sname is not a valid name on the server, any previous mapping for cname is dis- carded. gid cname=sname Map client group name cname to server group name sname, as above. param otherok=val If val is client processes with unmapped userids are granted world access to existing files on the server. Unmapped userids may never create files (who would own them?). If val is any- thing else, no access is permitted to unmapped client userids. param root=pathname Use pathname rather than / as the root of the filename hierarchy made visible on the client. EXAMPLES A friends file for a connection to alice over Datakit, shamash over TCP/IP, and bebop over TCP/IP without administrative help: alice - /n/alice d 0 0 tcp!shamash!400 - /n/sun d 1 0 bebop /usr/pjw/netb/zarf /n/bebop t 2 0 pjw Some except file rules: client dk!nj/astro/research param otherok=1 client * uid root= gid mail=other param otherok=0 param root=/usr/spool If the research machine calls as a client, the whole file system tree is visible, all userids including the super-user are permitted normal access, and user names unknown to the server are permitted world ac- cess. If any other machine calls, only the contents of /usr/spool are visible, root and unknown users are explicitly denied access, and processes in group mail on the client are treated as if in group other on the server. FILES client connection info log file for setup log file for zarf server control info SEE ALSO S. A. Rago, `A Look at the Version 9 Network File System', this manual, Volume 2 BUGS The scheme works only in a modest-sized, friendly community, as it re- quires a process per client, trust of clients' security, and common lo- gin names. File modification times are adjusted for clock-time differences between machines. Thus, when viewed across the network, identical files in- stalled on different machines by asd(8) may appear to have different modification times, and symbol tables of random libraries (ar(1)) may appear to be out of date. NETFS(8)