Gravelrash Posted June 25, 2016 Posted June 25, 2016 We will be configuring in a mode that allows both NFSv3 and NFSv4 clients to connect to access to the same share. Q. What are the benefits of an NFS share over a SAMBA share? A. This would take an article in itself! But as a brief reasoning, In a closed network (where you know every device), NFS is a fine choice. With a good network, throughput it disgustingly fast and at the same time less CPU intensive on the server. There are a lot of applications that support NFS "Out of the box" KODI being a common example. It's very simple to set up and you can toggle readonly on shares you don't need to be writeable. It only gets complicated if you want to start layering on security through LDAP/gssd. It's capable of very complex and complete security mechanisms... But you don't need them in this scenario. Q. Why are we doing this and not limiting to NFSv4? A. Flexibility, this will allow almost any device you have that supports reading and mounting NFS shares to connect and will also allow the share to be used to boot your clients from which will allow fast testing of new kernels etc. Q. Why would I want to do this? A. You can boot your dev boards from the NFS share to allow you to test new kernels quickly and simply A. You can map your shared locations in Multimedia clients quickly and easily. A. Your friends like to struggle with SAMBA so you can stay native and up your "geek cred" This HOWTO: will be split into distinct areas, "Section One" Install and Configure the server "Section Two" Configure client access. "Section Three" Boot from NFS share. (a separate document in its own right that will be constructed shortly). "Section One" Install and Configure the serverInstall NFS Server and Client apt-get update ; apt-get upgrade ; apt-get install autofs nfs-kernel-server nfs-common --install-recommends -f -y ; Now reboot sync ; reboot ; I will be making the following assumptions (just amend to suit your environment) 1. You already have a working system! 2. Your media to be shared is mounted via fstab by its label, in this case Disk1 3. The mounted disk resides in the following folder /media/Disk1 4. this mount has a folder inside called /DataConfigure NFS Server (as root) cp -a /etc/exports /etc/exports.backup Then open and edit the /etc/exports file using your favourite editing tool: Edit and comment out ANY and ALL existing lines by adding a “#†in front the line. Setup NFS share for each mounted drive/folder you want to make available to the client devices the following will allow both v3 and v4 clients to access the same files # Export media to allow access for v3 and v4 clients /media/Disk1/Data *(rw,sync,insecure,no_root_squash,no_subtree_check,nohide) Explanation of above chosen parameters rw – allows read/write if you want to be able to delete or rename fileasync – Increases read/write performance. Only to be used for non-critical files.insecure – This setting allow clients (eg. Mac OS X) to use non-reserved ports to connect to the NFS server.no_subtree_check – Improves speed and reliability by eliminating permission checks on parent directories.nohide - makes it visibleno_root_squash - *enables* write access for the connecting device root use on a NFS share Further explanations if you so desire can be found in the man page for NFS or from the following link http://linux.die.net/man/5/exportsStarting / Stopping / Restarting NFS Once you have setup NFS server, you can Start / Stop / Restart NFS using the following command as root # Restart NFS server service nfs-kernel-server restart # Stop NFS server service nfs-kernel-server stop # Start NFS server # needed to disconnect already connected clients after changes have been made service nfs-kernel-server start Any time you make changes to /etc/exports in this scenario it is advisable to re export your shares using the following command as root export -ra Ok now we have the shares setup and accessible, we can start to use this for our full fat linux/mac clients and or configure our other "dev boards" to boot from the NFS share(s)."Section Two" Configure client access. We now need to interrogate our NFS server to see what is being exported, use the command showmount and the servers ip address showmount -e "192.168.0.100" Export list for 192.168.0.100: /mnt/Disk1 * In this example it shows that the path we use to mount or share is "/mnt/Disk1" (and any folder below that is accessible to us) NFS Client Configuration v4 - NFSv4 clients must connect with relative address Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address) mount -t nfs -o vers=4 192.168.xxx.xxx:/ /home/â€your user nameâ€/nfs4 The mount point directory /home/â€your user nameâ€/nfs4 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs4 directory. Another way to mount an NFS share from your *server is to add a line to the /etc/fstab file. The basic needed is as below 192.168.xxx.xxx:/ /home/â€your user nameâ€/nfs4 nfs auto 0 0 NFS Client Configuration v3 - NFSv3 clients must use full address Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address) mount -t nfs -o vers=3 192.168.xxx.xxx:/media/Disk1/Data /home/â€your user nameâ€/nfs3 The mount point directory /home/â€your user nameâ€/nfs3 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs3 directory. "Section Three" Boot from NFS share. please refer to this document on creating the image https://github.com/igorpecovnik/lib/blob/master/documentation/main-05-fel-boot.md - there will be an additional HOWTO & amendment to this HOWTO to cover this topic in more detail. 3
Gravelrash Posted June 25, 2016 Author Posted June 25, 2016 Reserved : Please test / feedback any observations comments you have
zador.blood.stained Posted June 25, 2016 Posted June 25, 2016 (edited) Then open the /etc/exports file using the following command: nano /etc/exports Minor detail - let user pick their favorite editor, "edit file /etc/exports" should be simple enough. insecure – Does not mean the files are insecure but rather this setting allow clients (eg. Mac OS X) to use non-reserved ports connect to a NFS server. They are insecure anyway since you don't configure authentication or access limiting fsid=0 - declares this to be a v4 only share fsid=num|root|uuid NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device). As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option. For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing. Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctua†tion. Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike. TL;DR from my experience - explicit fsid parameter is needed when underlying filesystem doesn't support UUID (i.e. tmpfs) Edit: I mean for non fsid=0/fsid=root shares. nohide - makes it visible nohide This option is based on the option of the same name provided in IRIX NFS. Normally, if a server exports two filesystems one of which is mounted on the other, then the client will have to mount both filesystems explicitly to get access to them. If it just mounts the parent, it will see an empty directory at the place where the other filesystem is mounted. That filesystem is "hidden". The nohide option is currently only effective on single host exports. It does not work reliably with netgroup, subnet, or wildcard exports. no_root_squash - *enables* write access for the connecting device root use on a NFS share User ID Mapping nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable. Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anony†mous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash. By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option. Here's the complete list of mapping options: root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff. no_root_squash Turn off root squashing. This option is mainly useful for disk†less clients. Starting / Stopping / Restarting NFS Once you have setup NFS server, you can start NFS share using the following command as root exportfs -ra -a Export or unexport all directories. -r Reexport all directories, synchronizing /var/lib/nfs/etab with /etc/exports and files under /etc/exports.d. This option removes entries in /var/lib/nfs/etab which have been deleted from /etc/exports or files under /etc/exports.d, and removes any entries from the kernel export table which are no longer valid. "exportfs -ra" is enough to apply any changes made in /etc/exports Restarting nfs-kernel-server may be needed to apply changes made in /etc/default/nfs-kernel-server or to disconnect already connected clients "Section Three" Boot from NFS share. please refer to this document : https://github.com/i...-05-fel-boot.md Not exactly. This is not documented well, but I meant building image with "ROOTFS_TYPE=nfs" option, which creates small SD card image and rootfs archive. Edit boot script on SD, deploy and export rootfs on a server and you are done. Edited June 25, 2016 by zador.blood.stained Formatting... 2
sysitos Posted June 25, 2016 Posted June 25, 2016 Hi Gravelrash, I prefer a defined place for server shares. So I have already done within my automount&share script. So imho a good place would be /srv/nfs for nfs shares (/srv/smb for samba etc.) Disadvantages: You need an additional mount within this directory, but this is quick done by: mount --bind or mount --rbind Advanatges: You are more flexible and see what you have shared, permissions could be set too. Additional mounts could on the fly be shared by binding they in the parent share (valid at least for NFSv4 and samba). As I already mentioned, this is how my automount&share script is working, but I think, you was the only one who was interested in To you exports file the following will allow both v3 and v4 clients to access the same files # Export media to allow access for v4 clients ONLY/media/Disk1 *(rw,async,insecure,no_root_squash,no_subtree_check,fsid=0,nohide)# Export media to allow access for v3 clients/media/Disk1/Data *(rw,sync,insecure,no_root_squash,no_subtree_check,nohide) It is correct, for NFSv4 you need a root directory, defined by fsid=0. And there could be only one. So if you have Disk2, it can't be shared additional in this way. Or you mount Disk2 within Disk1, not the best idea That's why, my suggested solution is the better one. And NFSv3 clients could access the NFSv4 server share too, no need to share it twice. Remark: Some old NFSv3 clients have problems with NFS shares and file system boundaries (e.g. the mentioned Disk2 mounting within the mounted Disk1). These problems could sometimes be resolved by giving the correct share options (nohide etc.) and an unique fsid and a separate sharing entry in the exports file. Also be done (beside the fsid, but there is something within my mind) with my script But never-less, for some clients I would prefer a different sharing solution, if the shares are changing often. So I use samba with my mini server and kodi and GBit Lan. By the way, you could write down some advantages for NFS (lower overhead and so more speed on slower networks, better ACL handling, better usable on linux clients, easier sharing if you have permanent ip addresses). Regards sysitos 1
Gravelrash Posted June 25, 2016 Author Posted June 25, 2016 thanks for you feedback and comments - i will expand and modify the HOWTo with your feedbacks. the request for feedback is to make it more specific to the way people on here use NFS. whilst tryong to keep it as simple as possitble so anyone coming across this for the first time could also use it.
Gravelrash Posted June 27, 2016 Author Posted June 27, 2016 @zador - amended to include your comments @sysitos - I will have a look into your comments and see how i can amend the above to reflect them and also to include your automount script. this may be another HOWTO linked to this one. I like your idea and approach.
svkatielee Posted August 28, 2016 Posted August 28, 2016 Where is the final destination for the HOWTOs? Since this re-organization of the github vs forum, I can't find the discussion streams about the claimed tasks.
lomady Posted November 23, 2016 Posted November 23, 2016 apt-get update ; apt-get upgrade ; apt-get install autofs nfs-kernel-server nfs-common --install-recomends -f -y ; It is --install-suggests And there is another typo: exportfs -ra
zador.blood.stained Posted November 24, 2016 Posted November 24, 2016 It is --install-suggests Both variants are valid apt-get parameters so it's not a typo. And there is another typo: exportfs -ra If there is a typo here then I don't see it.
lomady Posted December 4, 2016 Posted December 4, 2016 Sorry, but --install-recomends does not work for me on Armbian. And as I discovered exportfs should be used instead of export Thanks for great tutorial otherwise!
trohn_javolta Posted March 2, 2017 Posted March 2, 2017 On 25.6.2016 at 2:36 PM, Gravelrash said: --install-recomends -f -y ; Small typo here. 1
Recommended Posts