Thoughts on NFS file sharing
There are a few things I conveniently left out when talking about sharing files in your home network. I was writing then that if your network has Windows devices, you should set up sharing using SMB, a protocol understood by Linux and Windows and if your network has only Linux devices, you should use NFS because it’s native to Linux and it’s faster. But the differences don’t end here.
This article is a sort of conclusion to a series I wrote on home networks, home servers and how to pull your data from a corporate black box cloud and return it to your private environment. Ironically, this end of a series is starting a new series on users and rights in a local network. The articles in this series will follow in the next days and weeks and will talk about LDAP and two widely used implementation: OpenLDAP and FreeIPA.
What’s in a file
You see files don’t just have content in them. Of course that’s the part we are most interested in but before we can see the content, we have to pass a rights check. Because every file also has a set of rights or permissions. Also every file has an owner. So you can start to imagine that the story gets a bit ugly.
So why should you care about file permissions anyway? The files are yours, they are created by you so you must be the owner and they are shared in your home network. What’s the problem? Well the devices in your network don’t really know who you are as a person. They just understand the users they have configured on them. Sure, you have a laptop, a desktop and a phone and everywhere you created the user radu so everybody should know that all files are his. But the user radu on your laptop is not the same as the user radu on your PC. And it’s definitely not the same as the Google user radu@gmail.com on your Android phone.
And now you are sharing files from your Raspberry PI server in your whole home network and have no care in the world about who owns the files, who has the right to see them or to change them at all. How could this be? If you remember what we did when we configured NFS, I quickly said we are just mapping the users that access the files to the local Raspberry PI user. And that was that, no explanation. Well it was exactly about this rights management situation.
SMB and NFS
When you request to see or to read a file, you have to present yourself to the operating system. That’s the only way the operating system knows how to handle your request: first, who are you? If you are user radu and I have a user radu configured and your IDs match, we are good. Note that it’s not just about the user name. Users also have an ID and it has to match.
Now, when sharing with SMB, this rights issue is handled by the SMB server. When you share a folder with SMB, in the SMB configuration file you specify the folder you want to share and you also specify a user. It’s not a system user, it’s a SMB user that has rights on that share. So the whole rights management is taken from the operating system and moved to the sharing service itself. So when you try to access this file over SMB from your laptop, you will be greeted by a login screen. And you don’t enter your credentials from your laptop here. You enter the credentials configured for this share by the SMB sharing service on the Raspberry PI. This does make things easier because the other option is to let the operating system handle the users.
And that’s exactly what NFS does. When asking for a file via NFS, I am sitting at my laptop making a request to my Raspberry PI. Two different devices with two different operating systems installed. They both have user radu because I created it, but I also created an admin user on my Raspberry PI. When you create a user in Linux, it receives an ID, usually starting from 1000 and going up by one with each new user created. So on my laptop I have user radu with UID 1000 and on my Raspberry PI I have user admin with UID 1000 and user radu with UID 1001. See the problem? Sitting at my laptop and making my request to my server, I am presenting myself as user 1000 because that’s my ID on my laptop. But the Raspberry PI has a different understanding of user 1000. On my Raspberry PI, user 1000 is actually admin. This is a conflict, and it must be resolved.
NFS user mapping
So now we come back to the weird and conveniently unexplained user mapping we did when we configured our NFS shares on our Raspberry PI. We said there in the NFS exports file this:
/mnt/storage/radu 192.168.68.0/24(rw,all_squash,no_subtree_check,anonuid=1000,anongid=1000)We defined the share found at /mnt/storage/radu and we made it readable and writable rw and then we said three things: all_squash, anonuid=1000, anongid=1000. Who is user with UID 1000 on the Raspberry PI? Well it’s the first user created for it. It’s admin, or however you named it when you built your home server. And who owns the files at /mnt/storage/radu? Well admin does because the files are on a disk connected to the Raspberry PI, managed by admin. And what does all_squash mean then? It means that when access is requested from all, all will be squashed or renamed 1000. In this way, anybody who asks for files in /mnt/storage/radu will forever be recognized by the NFS service as admin, the local Raspberry PI user. Order is again restored in the home network.
Note that this does solve the user recognition issue, but it opens up a separate problem. Actual rights. In this way, anybody who has access to my home network can access files on /mnt/storage/radu. Do we want this? Well for a disconnected home network, sure. If you close all ports to your home network and you have a separate guest network configured on your WiFi router, you are good. The only persons that will access the network shares are persons you trust and that login to your proper WiFi network. And if you want to access your files from the Internet, you can set up a VPN which gives you the same security as your own private home network.
Restoring proper user management
But what if you are not satisfied by this mapping? Maybe you want some privacy even inside your network. For example user radu to have proper rights and files accessible just to him, and other users the same. What we did before with user mapping is just a trick. It’s like performing magic in front of an audience, it’s not the real thing. The real thing is to have the same users configured everywhere in your network.
And yes, NFS and your Linux operating system would be satisfied if only you would have exactly the same users with the same UIDs configured on all your machines. Is this possible? Sure! You are the creator of your home network, surely you can configure every device in your network to have the same users. Well, except the phones? And also, when a new user enters the network you have to add it on all the devices again?
Yes, there is a better way but you are not going to like it. It’s called having an identity server on your Raspberry PI and that’s exactly what the next two articles in this series talk about.
For now, I will stop here. Having an identity server in your network is a whole new kind of madness but we will talk about it in detail. I strongly advise not doing this. If you can be satisfied with NFS user mapping for your home network, stop here. Set up a VPN, set up that guest WiFi network, try to set the boundaries to your private home network in other simpler ways. If you really want that credential login, use SMB. The following articles will be a good read but purely academic.
I tried to control every aspect of my network, including the users and I did set up an identity server for a while on my Raspberry PI server but in the end I quit and returned to user mapping simply because I have all the security I need in my network by using VPN and a guest WiFi network. But if you are interested to see how you can setup users on your server and then login on your client by querying the server, the series will be a technical treat. See you next time!
