In our previous lessons,
we learned how to work with local file systems and local block storage devices.
Basically data that exists on the same system that we're logged into.
But sometimes we need data that resides on a different system. In
this lesson, we'll learn how to use remote file systems.
And one of our next lessons how to use remote block devices.
Let's go through these scenarios. In order
there are multiple protocols that allow us to access remote file systems.
Now a protocol in a way is a language that a client and server use to communicate.
They need to speak the same language so that they can understand each other.
Negotiate a connection and transfer data.
Linux supports many protocols for the purpose of sharing file systems,
but for sharing data between two Linux computers,
the network file system protocol is most often used.
This is also abbreviated as NFS.
Let's see how we can use NFS on Linux,
there are two parts to using NFS,
setting up the NFS server and then setting up the NFS clients
on the server.
We configure everything to allow it to share a file system with the world.
And on the client side,
we configure everything to allow them to mount
the remote file system from that server.
Let's jump right into the first part, setting up the NFS server.
Then we'll explore how to use NFS on the client side as well.
First, we type the path into the directory. We want to share.
It could be something like slash SRV slash homes or slash NFS
slash disc one slash backups or whatever we might wanna use here.
Usually we'll want to point to the path where a file system is mounted,
but we can also point to a subdirectory belonging to that file system.
Next, we need to choose who or what can access the share.
In other words,
we specify which NFS clients should be allowed to use this remote file system.
In this example, we can see hostname one,
that's the hostname of a computer on our network.
These host names can potentially take more
complex forms such as example.com or server one.example.com
instead of host names. You can also use IP addresses here.
So we could replace hostname one in
this highlighted line with something like 10.0 0.0
0.9 or whatever the IP address of the computer accessing the share would be.
And there's a third option as well.
If we want to allow an entire range of IPs to access the share,
we can use the Cidr notation which we learned about in our networking lessons.
For example,
if we want to make this share accessible to any computer with an IP address between
10.0 0.16 0.1.
The way to 10.0 0.16 0.2 55 we can type in 10.0 0.16 0.0 slash 24 here.
So we could replace hostname one in this
highlighted line with something like 10.0 0.0 0.9
or whatever the IP address of the computer accessing this share would be.
And there's a third option as well.
If we want to allow an entire range of IP S to access the share,
we can use the cidr notation which we learned about in our networking lessons.
For example,
if we want to make this share accessible to any computer with an IP
address between 10.0 0.16 0.1 all the way to 10.0 0.16 0.2 55.
Then we can type in 10.0 0.16 0.0 slash 24. Here.
Finally, between parentheses, we include the export options. In
this case, they are RW sync and no subtree check.
What's interesting in this highlighted line is that we can
enumerate multiple hosts that should be able to access the share
and we can do it on the same line.
In this case,
we noticed that the slash SRV slash homes directory is
also shared with a second host called hostname two.
And this includes slightly different export options
notably, this uses the RO option instead of RW.
Now let's explore what these export options mean.
The important options to know are RWROR sync async,
no subtree check and no root squash RW stands for read write.
This allows clients mounting the share remotely to both
read and write to this file system or subdirectory
RO stands for read only. This allows clients to read
but not write.
Sync is for synchronous rights of data.
That is NFS ensures that data written by a
client is actually saved on the storage device.
Before reporting the operation is successful. Async is for asynchronous rights.
A client can issue multiple right requests and NFS can report that the
rights are completed even before they're actually saved on the storage device.
Async allows clients to do things faster.
But it does not guarantee that all the changes are actually stored.
So we can end up in a situation where NFS
reports to the client that the right is complete,
even though it isn't actually committed to the storage device yet,
then if the server reboots unexpectedly that right operation could be lost,
think is slower, but it guarantees that when a write is reported as being complete,
it's actually stored on the device.
No subtree check disables subtree checking.
Now, normally with NFS, we'd want to export an entire file system.
For example,
let's say we have a backup disk on the NFS
server and we mount it to slash NFS slash disk one
and then we'll export slash NFS slash disc one as an NFS share.
But we can also export a subdirectory here like
slash NFS slash disk one slash backup slash databases.
If subtree checking would be active,
the NFS server would always check if the requested
file resides in the specific subdirectory that was exported,
which can cause a few issues when files
are renamed or moved to another subdirectory.
Subtree checking is basically intended as an extra security check,
but it has some drawbacks and a few performance implications.
That's why by default, no subtree check will be assigned to all NFS exports.
Even if we don't specify this option ourselves.
No root squash allows a root user on the NFS client
to also have root privileges on a remote NFS share.
They mount
by default NFS squashes root privileges.
That is if we're root on the client and we mount an NFS share,
then we won't be able to read and write as root on that remote file system,
we'll be squashed or downgraded to regular user privileges,
all read and write requests as root on the client will
be mapped to a user called nobody on the server.
And this is a mild security measure that ensures that root users
on NFS clients cannot do anything they want on remote file systems.
If we want to deactivate this behavior, we can also use the Noroot squash option.
That way root on the client will be treated as a root user on
the remote file system to see information
about the Etsy exports file including other mount
options and syntax specifications. We can use this command
man exports
now that we understand how to define an NFS share on our server.
Let's say we want to add our own line.
What would we write if we wanted to share the
slash Etsy directory with a computer with the IP address?
127.0 0.0 0.1.
And what if we also wanted that computer to only be able
to read files from the share but deny right access to it
pseudo export, FS dash R,
the dash R option stands for re export.
You can think of it as doing a refresh based on the Etsy export file.
It will share what's defined in that file
but also unshare whatever has been removed.
Dash V stands for verbose
and that is detailed output.
This will show us what shares are currently active but
also the export options that are associated with each one.
Notice that in our case, we only used ro as our option,
but there are many more options active for this share.
That's because the NFS server will assign some options by default,
even if they are not explicitly defined by
the administrators in the slash XC slash exports file
to wrap up. This section here are a few tips.
We can also use wild cards in the hostname field. In our Etsy exports file.
For example,
to share this directory with all computers
that have a hostname ending in example.com,
we could add a file like this.
The asterisk is the wildcard sign that
matches anything that may come before example.com.
So clients with host names like server one.example.com or
mail.example.com will be allowed to access the share.
The asterisk is the wildcard sign that
matches anything that may come before example.com.
So clients with names like server one.example.com or
mail.example.com will be allowed to access the share
and to share with any client. We can simply use the asterisk sign alone.
Now,
it's important to remember not to add any extra
spaces between the asterisk and the mount options.
Same rule applies when you use a hostname or an IP address
the field where we define the clients allowed to access,
the share should be glued together with
the open parentheses that includes the options.
Now let's move on to the client side. Things are much simpler here.
First, we need to ensure that we have the utilities necessary to mount NFS shares.
Now that we already shared the Etsy directory on our server.
How would we mount it from a remote client?
Well, we already learned about the mount command in previous lessons.
All we need to do is adapt it to this use case
mount something from an NFS server with IP address 127.0 0.0 0.1
mount, the Etsy file system or directory from that server.
Finally, if we want this NFS share to be automounted at boot time,
we'd go through familiar steps.
First, we'd open the FSTAB file for editing.
Then we'd add a line like this.
The only differences compared to what we did in FSTAB and earlier lessons is
that the source of this mount specifies an IP address and a remote directory.
And in the field where we normally specify EXT four or XFS as the file system type,
we entered NFS.
The rest is similar
where we specify mount options.
We can write defaults to let NFS auto configure its mount options.
Of course, if you need specific mount options,
you can just enumerate them here like we did in our previous lessons,
multiple values separated by commas.
Finally, since this directory is not local,
we don't need to check the file system for errors.
So our last two fields should be 00.
This covers the essentials of creating NFS servers
and mounting remote file systems on NFS clients.
Let's jump into our next lesson.