On 01/20/14 18:12, Chris Stankevitz wrote: > On Sun, Jan 19, 2014 at 10:57 PM, Alan McKinnon <[email protected]> > wrote: >> That's how it is supposed to work. nfs is a Unix filesystem, it obeys >> Unix user and permissions (unlike say VFAT or smbfs where it has to >> fudge these things). NFS will mount the filesystem using whatever is set >> on the server. You cannot override the permissions the server has set >> from the client > > Alan, > > Thank you for your help. I was trying to use NFS because I always > thought it odd that I have to jump through a bunch of samba hoops to > share data among gentoo boxes. Is this a fair understanding: > > When setting up an NFS server to share data with people, first collect > a list of UIDs from people around the world who will ever want to > connect to this server. Modify the NFS server settings to incorporate > these UIDs. If you cannot generate such a list, then an NFS server > might not be right for you. > >> You probably want to tweak your squash settings. > > I never have heard that term before, but I'm hoping to find something > like this: "Normally NFS requires you go compile a list of UIDs of > people around the world who will ever connect to your server. The > "squash settings" help you avoid that. > > Thanks again, > > Chris
You're on the right track :-) For a full understanding, look back to where NFS comes from: Sun Microsystems wrote it so that home directories could be stored on a central server and mounted by the workstation. Often, systems dirs like /usr were also stored on that server. It's a classic thin-terminal setup. To work properly, the entire network had to be trusted, there was one root accounts and no user ever got near it, it was the exclusive province of the sysadmin. And there was no chance of spoofing things by fiddling with physical wires. User account control was often done with NIS (aka yellowpages in the early days) to have central control and there were no local users on the workstations. NFS is still the most efficient and fastest network file share out there (it beats the pants off SMB) but you do have to deal with this issue of UIDs - nfs only understands UIDs, not usernames (it is Unix after all and the username is only a decorative name). So if you and your spouse both have Linux laptops, both have UID=1000 respectively and want access to an NFS share, the server can't tell you apart. So, if you want rw access, you have to fudge it, there's a few neat tricks: 1. Set up Unix accounts for every user on the server with unique UIDs. Create the user's account on their workstation with the same name and UID as the server and enable rootsquash on the server (more on this later). When accessed, the server looks at the UID making the request and applies normal Unix permissions. or 2. Set up a separate share for each user and set their IP for write access in /etc/exports on the server. You may or may not want to give everyone else read access. For this to work right, the workstations should use dhcp with reserved leases to guarantee the address. Neither of these solutions is entirely satisfactory wrt real security as both are easily circumvented. It works best if all the users know to behave themselves and nothing is really sekrit, you just want to orevent people accidentally clobbering each other's stuff. Most NFS servers in the real world are thus file shares and permit read-only access to all users. Root or an admin updates and writes to the share by some other means (scp, rsync or local edits). All this is true for NFS versions 1 through 3. NFSv4 is an effort to fix this using real usernames and identifying tokens. It's a huge learning curve, much like figuring out AD or kerberos. Squash: This is another fudge action. Giving user access over NFS can be OK for trusted network, but what if root on the client is making the request? Do they get root access on the server too? Normally, they would. So squash was invented - when root access comes over the wire, the server changes it from UID=0 to something else (usually nobody) and then applies Unix permissions to that account. Config setting norootsquash disables this security feature. There's also an "allsquash" which changes all access to the nobody user - very useful for shares that are globally read-only. The man pages are good quality: man 5 nfs (client side) man 5 exports (server side) Shout back if you need more guidance, nfs can often be gotten to work well if you are clever about it -- Alan McKinnon [email protected]
