Nfs

NFS

Network File System

Revised November 16, 2003

Professor Tom Mavroidis

What is NFS?

• The Network File System (NFS) is a distributed file system that allows users to access files and directories located on remote computers and treat those files and directories as if they were local. For example, users can use operating system commands to create, remove, read, write, and set file attributes for remote files and directories.

The NFS HOWTO’s

• You can find the NFS how to at

• http://www.linuxdoc.org/HOWTO/NFS-HOWTO/

• http://nfs.sourceforge.net/nfs-howto/

RFC’s

• You can follow the evolution of NFS at:

• NFS protocol version 2 [RFC1094]

• NFS protocol version 3 [RFC1813]

• NFS version 4 Protocol [RFC3010]

What’s new in Version 4

• NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4

operate well in an Internet environment.

Introduction

• Linux has multiple types of file systems available to it

• NFS is just one of these types

• NFS was developed by Sun Microsystems in 1994

• NFS allows fill or partial file systems from other hosts to be mounted to the local file system

Three Layers

• NFS has three layers

• The RPC layer which passes the data between hosts [RFC3010]

• the XDR layer which provides for machine independence of the data [RFC1832]

• and the top layer which consists of the mount protocol and the NFS protocol

Disadvantage to NFS

• Limited security

• Clients and servers trust each other unconditionally

• Host names can be spoofed (a machine claiming to be another)

Starting up NFS

• There are three key things you need to start on Linux to make NFS work.

/usr/sbin/rpc.portmap

/usr/sbin/rpc.mountd

/usr/sbin/rpc.nfsd

• These things should start up automatically at boot time. The file that makes this happen is "/etc/rc.d/rc.inet2"

You can verify that these are running by issuing this command (as root)

• rpcinfo -p localhost• program vers proto port• 100000 2 tcp 111 portmapper• 100000 2 udp 111 portmapper• 100005 1 udp 679 mountd• 100005 1 tcp 681 mountd• 100003 2 udp 2049 nfs• 100003 2 tcp 2049 nfs

• Note that there are two copies of each running, one for tcp and one for udp protocols.

Ways to reduce security risks

• Use the secure,nosuid and root_squash options when exporting a resource

• Disallow SUID execution

• Map root access to the anonymous UID

• Mount few file systems as RW

• Hosts in the exports file should be FQDN (Fully Qualified Domain Names)

Similarities

• NFS is similar to SMB (Server Message Blocks)• NFS uses a different protocol than SMB and

only shares files• NFS was created for UNIX• NFS uses a client /server relationship to handle

file sharing• Any machine can be a client and a server at the

same time

Notes

• NFS makes files on a remote host appear as part of the local host’s file system

• NFS allows you to centralize administration of disks instead of duplicating directories on every system

• Only the servers need to be backed up if clients do not store data locally

Principles

• On Linux we split the disk into Partitions (see next slide)

• Each partition has a structure imposed on it

• The Linux tree appears as one set of files and directories by mounting onto it during bootup

Linux Tree

During bootup

• On initial boot the Linux file system consists of only a mount point at the top of the tree

• Linux startup scripts then issue mount commands to build the file tree

• When mounting an NFS file system you specify the name of the host that the files are on instead of the local disk

NFS Client/Server

• Must mark the files and directories to be shared (known as resources)

• The system that imports or mounts resources from a NFS server is known as a NFS client

• An NFS client may only import a resource if it has been exported by an NFS server

• Re-exporting resources are not allowed

NFS Server exports

• Resources that need to be shared must be exported by the server

• Any file system or subset may be exported

• A directory or sub-directory may be exported (if a directory is exported then a parent directory can only be exported if it exists on a different device

• Only local resources may be exported

NFS Client

• Client must identify the server host it wishes to import resources from (those resources must have been exported by the server)

• Imported resources appear as local files and directories

• No restrictions on the number of resources a client may import

Client options

• Client may import a resource as read only even though it has been exported as read/write.

• There are two types of import, hard and soft• Hard is recommended for read/write, it will

continue to retry operations until the server responds.

• Soft causes the client to give up after a certain time

Protocols

• Three separate layers– RPC (Remote Procedure Call)– XDR (External Data Representation)– Top Layer

• two protocols– Mount protocol(negotiates the import between the client

and the server)

– NFS protocol(platform independent, deals with passing blocks of data back and forth between client and server)

UDP

• NFS runs over UDP (sounds strange)– Stateless (client does not detect absence of

server)– Idenpotenet (request can be sent more than

once to the sever without negative effects) (client can keep retrying its request until the server replies)

Application Layer Protocol

• NFS is an application layer protocol

• Mount protocol is system dependent and supports the import of remote procedure calls

• NFS protocol is operating system independent

RPCs Remote Procedure Calls

• RPCs allow procedure calls similar to local procedure calls to be performed on a remote machine

• NFS uses Suns Open Network Computing (ONC) Remote Procedure Call as defined in RFC 1057

• RPC servers use a port mapper to facilitate communications between client and server

RPCs

• Remote procedures are identified by a program number and procedure number

• Program number specifies a group or related procedures

• Procedure number identifies a procedure within that group

• Each set of procedures has a version number

Client calls

• A client calls a remote procedure by specifying its program number, version number, and procedure number

Port Numbers

• Are allocated dynamically by a server

• Client discovers the servers port number by sending a request to the port mapper on the server. The port mapper replies with the port number

• The server requests a port number on startup from its host machine. The server returns the port number to the port mapper

Portmapper

• In UNIX the port mapper is implemented with the rpcbind or portmap server

• Some services, mainly SUN's NIS and NFS services, don't use a static port like most services, but instead register themselves via RPC. To connect to an NFS server you first ask RPC which port to find it on. It may even be the case that the service isn't available until you request it via RPC.

If you want to list the registered RPC services run rpcinfo:

rpcinfo -p localhost

[tmavroid@bigbox tmavroid]$ rpcinfo -p localhost program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100004 2 udp 644 ypserv 100004 1 udp 644 ypserv 100004 2 tcp 647 ypserv 100004 1 tcp 647 ypserv 100007 2 udp 663 ypbind 100007 1 udp 663 ypbind 100007 2 tcp 666 ypbind 100007 1 tcp 666 ypbind 100005 1 udp 635 mountd 100005 2 udp 635 mountd 100005 1 tcp 635 mountd 100005 2 tcp 635 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs

100009 1 udp 873 yppasswdd

nfsstat

• Gives statistics on client and server RPC calls and client and server NFS processes.

• -u option makes a UDP call

• -t option makes a TCP call

XDR (External data Representation)

• Deals with sending complex data types between machines of different architectures

• Standardizes the formats of data sent across a network

• Programs translate data to XDR’s canonical (A canonical format is the "preferred" format) and sends it across the network

Top Level Formats

• Two separate formats– Mount protocol

• responsible for negotiating the mapping of the remote drive

• operating system specific

– NFS Protocol• operating system independent

• Oldest common version of NFS is v3 (RFC 1813)

Limitations of NFS

• Linux symbolic links cannot be supported if the remote system does not support them

• Deleting files while they are open– Linux doesn’t free disk blocks until the file has

been closed

• Access to device files (Linux special files and DOS LPT devices is not supported

• File locking becomes difficult

EXPORTS

• Means making a local directory of file available for mounting over the network by NFS clients

• NFS server maintain a table of exported resources– $ exportsfs #shows current exports table– $ exprotsfs -a #exports all resources in exports

file

EXPORTS file and Options

• Exports file is a text file• Specifies those resource that may be exported• The file is /etc/exports• One line per resource containing the path to

the directory to be exported followed by a space separated list of hosts that may access the resource followed by a parenthesized list of options

Export file options

– Ro - resource is marked read only and may not be changed by this host

– root-squash - Map request form UID or GID 0 (root) to the anonymous UID/GID

– rw - read/write– sync - writes will be immediately written to

disk• /exports/diskless-root diskless*.hypothetical.com(rw,no_root_squash)

Mounting

• Syntax is as follows– $mount -t nfs -o optionlist hostname:/export /localpath

• Instead of a device name a hostname:/export pair is given

• A hostname must refer to a system that can be contacted by the local system

• The /export must refer to an exported resource on the remote system

Mount options

• Hard mount is recommended for file systems that are mounted read/write

• intr option assures that processes accessing hard mounts may be interrupted it the NFS server crashes

• If the file system is regularly mounted place an entry in the /etc/fstab file

Mount -a -t nfs

• In rc.local will make sure that all NFS resources in /etc/fstab are mounted

• fstab entry– hostname:/exportdir nfs rsize=8192,wsize=8192,timeo=14,intr 0 0

• too large a value for rsize and wsize could cause problems with lost packets and retransmissions

Creating an NFS Export

• Edit the /etc/exports file on the server

– /home/yourname xxx.xxx.xxx.xxx(rw)

• stop and restart the server

– # etc/rc.d/init.d/nfs stop

– # etc/rc.s/init.d/nfs start

• edit the /etc/fstab on the client

– xxx.xxx.xxx.xxx:/home/yourname /mnt/testnfs nfs defaults 0 0

• Create the mount point on the client

– # mkdir /mnt.testnfs

• Mount the /mnt/testnfs directory on the client

– # mount /mnt/testnfs

Security

• NFS is a major security headache

• NFS uses simple authentication bases on IP address and user ID

• Use a secure authentication scheme

• Turn on Root-squashing

• Configure NFS to listen only on low numbered ports

So in summary

• Even with its simple security there are times you are forced to use NFS such as for– Diskless workstations

• NFS gives you a rich alternative to remote file/directory sharing

• Useful for remote loading of machines

Setting Up Suse Specific NFS

• Verify that the NFS package has been loaded

• rpm -q knfsd

Verifying the NFS daemons

• If the portmap daemon is not running, you need to start it up first before you start up the NFS daemons. You can do this with the command:

• rcportmap start • Once the portmap daemon is running, you

can start up the NFS daemons with the command:

• rcnfsserver start

You can verify that the rpc.knfsd, rpc.kmountd, and

portmap daemons are running • ps ax | grep nfs• 323 ? SW 0:00 [nfsd] • 324 ? SW 0:00 [nfsd] • 325 ? SW 0:00 [nfsd] • 326 ? SW 0:00 [nfsd] • 327 ? SW 0:00 [nfsd] • 328 ? SW 0:00 [nfsd] • 329 ? SW 0:00 [nfsd] • 330 ? SW 0:00 [nfsd] • 662 ttyp1 S 0:00

• ps ax | grep mount

• 313 ? SW 0:00 [rpc.kmountd] • 673 ttyp1 S 0:00 • rcportmap status OK

Starting the portmapper

• If the portmap daemon is not running, you need to start it up first before you start up the NFS daemons. You can do this with the command:

• rcportmap start

Start up the NFS daemons

• Once the portmap daemon is running, you can start up the NFS daemons with the command

• rcnfsserver start

Note:

• If the /etc/exports file does not exist or is empty, the NFS daemons will not start.

• You can give NFS access to a file system by setting it up in the /etc/exports file. The file is set up on the exporting server. You can create a sample file entry by opening the /etc/exports file. Then you can add an entry like:

• /usr/local/share myserver.mydomain.com(ro)

Starting and Stopping the Server

• To stop the NFS server, use the command:

• rcnfsserver stop• You can restart the NFS process with

the command:

• rcnfsserver restart

Access options

• ro read only Only permits reading

• rw read write Permits reading and writing. If both ro and rw are specified, rw takes priority.

• root_squash client Anonymous user (nobody) access from client.

• no_root_squash client Access request privileges per the privileges of the client root. Useful for diskless clients.

• squash_uids and squash_gids Specify a list of UIDs or GIDs that should be subject to anonymous mapping. A valid list of IDs looks like this: squash_uids=0-15,20,25-50

• all_squash all access Processes all requests for access as anonymous user.

• anonuid=uid root_squash or all_squash when options are set will assign a group ID to an anonymous user request.

• anonuid=gid root_squash or all_squash when options are set will assign a group ID to an anonymous user request

sample  /etc/exports  file  

• A  sample  /etc/exports  file  is  shown  in  the  man  pages  for   exports  

• # sample /etc/exports file • / master(rw) trusty(rw,no_root_squash) • /projects proj*.local.domain(rw) • /usr *.local.domain(ro) @trusted(rw) • /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) • /pub (ro,insecure,all_squash) • /pub/private (noaccess)

# sample /etc/exports file

• This is just a comment. Any line or character string can be converted to a comment and disabled by entering a # symbol. Everything from that point to the end of the line is considered to be a comment

/ master(rw) trusty(rw,no_root_squash)

• This says that the root directory (/) is exported to the servers: master - whose rights are read-write

• trusty - whose rights are read-write and the access rights of the client root can be the same as the server’s root

/projects proj*.local.domain(rw)

• The directory /projects is read-write accessible to all servers whose names match the pattern proj*.local.domain.

• This includes proj.local.domain, proj1.local.domain,projprojproj.local.domain and so forth

 /usr *.local.domain(ro) @trusted(rw)

• Any systems whose hostname ends in  .local.domain is allowed read-only access. The  @trusted netgroup is allowed read-write access

/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)

• The directory /home/joe is accessible to pc001 for read-write access; all requests for access are processed as anonymous users. The anonymous UID number is set to 150 and the anonymous group ID is set to 100.This is useful when using a client that is running PCNFS or an equivalent NFS process on the PC. Since the PC IDs do not necessarily map to the UNIX IDs, this allows the proper file attributes to be set.

/pub (ro,insecure,all_squash)

• The directory /pub is accessible as read-only. The option in this entry also allows clients with NFS implementations that don't use a reserved port for NFS and process all requests as an anonymous user

/pub/private (noaccess)

• The directory /pub/private does not allow any NFS access.

Accessing data remotely with NFS

• To mount a remote file system on your local system, the mount point must exist. The mount process does not create the mount point automatically. The process of making the mount point is to use the Linux  mkdir  command. To make the /usr/local/share mount point, enter:

• mkdir /usr/local/share

File attributes and ownership

• Typically you do not need to worry about file attributes and ownership when making an NFS mount point. The NFS access rights will usually supersede any rights established for the directory.

Once you have created the mount point, you can use the mount command as follows:

• mount -t nfs nfs_host:share_dir local_mount_dir • where:• -t nfs Says to do the mount as an NFS mount. This is now optional

because if you explicitly specify the directory to be mounted as host:directory the  mount command knows that it is an NFS mount.

• nfs_host Is the host that is exporting the file system to be shared.

• share_dir Is the actual directory that is to be shared.• local_mount_dir Is the directory on the local host where the remote

directory is going to be mounted.

• As mentioned earlier, this mount point must exist.

Assignment

• Setup your machine as a NFS server and share out a directory. Have one of your classmates remotely mount the nfs share from their machine.

• Once this is set up show me the results.