| The Exports page,
the one that describes
NFS. |
| As described in the
/etc/samba/smb.conf page,
the Network Flesystem protocols for the common user are two: Session Message Block (described in /etc/samba/smb.conf) and Network Filesystem. This page is about Network Filesystem (NFS). Q: Isn't ftp another network filesharing protocol? A: File Transfer Protocol is just what it says. Thansfer files [from - to] the remote ftp server's directory. Network filesharing operations are wider than that. A network filesystem is a method to extend all our disk operations beyond the local disks, and in reality to extend our filesystem tree over the network. For example, if we need to edit a file in an ftp site, we have to: 1) download it in a directory 2) edit and save it and 3) upload the edited file. If we need to open a media file from an ftp site, in reality we: 1) download it in a directory 2) open it locally. In Network Filesystem protocols none of the above steps would be necessary. The NFS service is mostly used between Unix-Compatible hosts, but there are NFS servers & clients, usually commercial, for MS Windows and Apple Mac. A Little Theory For our computer to work as an NFS Server, first the nfsd.o kernel module must be present. Then pc.nfsd (the user level part of the NFS service) is started as a process, if correctly defined in the basic configuration files. Then, rpc.mountd is run to satisfy clients. Try man nfsd to read all of the above in a better way :) .... and more .....
If I shared my /home/micro via SMB in host athlon then: I would give a sharename like microhome and a description like Micro Home and the share would be accessed like this: //athlon/microhome If I shared my 'home/micro via NFS in host athlon then: No sharename or description would be necessary and the share would be accessed like this: athlon:/home/micro
When an NFS share is mounted in the client host, permissions and privileges are kept considering user id. Q: UID? Not username? A: The real criteria for permissions in a Unix Server is the uid, not the username. The Username is a human understandable conversion. For Unix I am not micro. I am 1001 and in an NFS share - if permitted in the server's share configuration - I inherit the permissions of user 1001 in the server. So, if jane is server's user 1001, for the server's NFS service I am jane, not micro. For practical reasons I've created all the users in all my hosts in my network with the same UIDs. micro is 1001 for Athlon, Filer And Pentium. Q: This is too complicated when users are too many! A: Not if you have created a script to add them. Furthermore, user authentication can be centralized using NIS (Network Information Services) and this issue would be a minimal task. But then, a NIS server would have to be constantly up and online. NFS has certain advantages and disadvantages. Advantages: In every Unix - Compatible OS all users have to authenticate, therefore the NFS service always knows about user ID. To mount an NFS share, one must know the exact path in the server, so just "browsing" a server for shares is not possible. Disadvantages: Network actions may not be encrypted. This can be a disadvantage for all network activities, not just NFS. There are tools to alter the UID, therefore imitate another user. This may be dangerous considering shares with read-write permissions in home directories. A Little Practice If the NFS server is up and configured properly, then the NFS sharing configuration is read from: /etc/exports
try man exports for many more options When you alter the /etc/exports, please don't reboot for applying changes. Just issue the command: exportfs -a to export according to /etc/exports To unexport all shares, try exportfs -ua exportfs can add-remove exported shares in real time, without the need of a configuration file. Try man exportfs. Usability Considering that the "holes" are "closed" therefore sequrity is not a burning issue, NFS can be used for two major tasks in a modern Unix - GNU/Linux - *FreeBSD network environment: Home Domain Home directories are centralized in a single server and any user can access his/her home from anywhere from the LAN/WAN/Internet. So, user configuration, files, operating environment and desktop are by default portabe into the network. This works better if combined with a NIS server (possibly served by the same machine that serves the /home). Diskless Hosts Computers without local disks can find all the prequisites to run (/etc /usr /home /var etc.) from network shares. The root of thir filesystem tree does not have to be the same as the server's one. And the computers can run in groups. For example, the server may export /usr/local/group1 to a group of computers with identical hardware, therefore identical configuration, which will be mounted as "/" to every client. The option "no_root_squash" may be practical in this case. If TFTP (Trivial FTP - an unauthanticated service) is combined, then these clients may not even have the kernels locally! The kernels can be downloaded from the network also. Of course, these tasks are not exclusive one to another, and more tasks - not so "heavy" ones - can be assigned to an NFS server. Happy sharing. |