How do NFS permissions work?

[Red Squirrel]

I'm not finding much info on google.

I setup NFS as per resouces I found, but when I go to mount I get a permission denied error. I'm guessing this is because I am using the local root account, and I would need to use a domain account, that has permission to the path.

Do I need to join the client to the domain? I'm not too sure how all this is suppose to work.

 

[Platypus]

I'm not finding much info on google.

You must not have looked for longer than .03 seconds then...

http://nfs.sourceforge.net/nfs-howto/ar01s03.html#config_server_setup

 

[Red Squirrel]

You must not have looked for longer than .03 seconds then...

http://nfs.sourceforge.net/nfs-howto/ar01s03.html#config_server_setup

Actually that's the article I read.

It mentions nothing about user permissions, only IP permissions which I have set.

I managed to get it working, but I'd still like to know how it deals with the user permissions. ex: do I need a domain, or do I just create a user on the client named the same as on the server, etc, what does it chmod / chown as locally vs on server etc...

 

[Platypus]

Actually that's the article I read.

It mentions nothing about user permissions, only IP permissions which I have set.

I managed to get it working, but I'd still like to know how it deals with the user permissions. ex: do I need a domain, or do I just create a user on the client named the same as on the server, etc, what does it chmod / chown as locally vs on server etc...

It does actually mention very specifically how that all works.What more do you want to know about user permissions? They are set locally and exported. It sounds like you have no idea how NFS works so I would stop blindly configuring it and read up on it.

If you're not using NIS or LDAP, then you are going to have to either have shitty permissions or you're going to have to play games with group memberships. (IE locally have a specific group have ownership and then on each box set up the same group).

You were getting permission denied as root because you either did not have the proper IP specified in your /etc/exports file or your permissions were not set up properly in the same file.

I would heavily advise against using the no_root_squash parameter. I would also be very careful who you give access to within said group.

If you need more granular permissions I would advise against using NFS in favor of something like Samba.

 

[Red Squirrel]

I actually have samba setup but what I like about NFS is you can add it to fstab so it auto mounts. This should mostly be used in SAN environments where the rest of the network does not have access to the NFS server, though I'm not quite setup that way yet.

I want to try to keep my files centralized to make backups easier when I add new servers. So all my apps that I'm working on will be in my "dev" folder on my central server, but I actually execute those apps off various servers. If something screws up it wont take the main server down.

 

[Platypus]

I actually have samba setup but what I like about NFS is you can add it to fstab so it auto mounts. This should mostly be used in SAN environments where the rest of the network does not have access to the NFS server, though I'm not quite setup that way yet.

I want to try to keep my files centralized to make backups easier when I add new servers. So all my apps that I'm working on will be in my "dev" folder on my central server, but I actually execute those apps off various servers. If something screws up it wont take the main server down.

You can do the exact same thing in /etc/fstab with Samba given that you're running a modern Linux OS with support for cifs. (read up on mount.cifs or mount -t cifs)

You really need to read up on the limitations of NFS if you plan on using it in production. Specifically stale mounts and what happens to remotely exported volumes if your local copy disappears from the network. I would also look into the hard/soft paramters for fstab and choose what makes the most sense for your infrastructure.

 

[Red Squirrel]

You can do the exact same thing in /etc/fstab with Samba given that you're running a modern Linux OS with support for cifs. (read up on mount.cifs or mount -t cifs)

You really need to read up on the limitations of NFS if you plan on using it in production. Specifically stale mounts and what happens to remotely exported volumes if your local copy disappears from the network. I would also look into the hard/soft paramters for fstab and choose what makes the most sense for your infrastructure.

Was not aware samba could do this. How do I input the password though, does it have to be clear text? Guess I'll do some research on it.

So NFS is no good? I always had the impression it was made specifically for very fast access of data over Ethernet and made for SANs and stuff while samba is for Windows to access Linux.

 

[Red Squirrel]

Ok so got it working with samba, guess this will be easier, only need to worry about managing one sharing system.

Now one more thing, on the remote side the permissions show as IDs. Any way to fix this? Or should I even worry about it? It works ok so far.

 

[Brazen]

I don't know why Platypus is so negative about nfs. Between servers it's a snap to keep track of users and groups (at least in a small server farm with a single admin it is). You just have to be aware of the uids and gids of users and groups used in nfs file permissions. The thing I like about nfs between linux boxen, is that it is way faster than samba/cifs.

I do something like this at home. I have one file server with a 1TB of data on redundant drives. I use nfs to share that out to a couple of application servers I use for development or just stuff I like to beat up on and I don't want playing with the apps to interfere with my clean, reliable primary server.

If you wanted some security, you could tunnel the nfs shares through stunnel. For business though, I use a SAN and would probably recommend against nfs because of performance (even though faster than cifs, it's still not as fast as iSCSI).

 

[Platypus]

I don't know why Platypus is so negative about nfs. Between servers it's a snap to keep track of users and groups (at least in a small server farm with a single admin it is). You just have to be aware of the uids and gids of users and groups used in nfs file permissions. The thing I like about nfs between linux boxen, is that it is way faster than samba/cifs.

I do something like this at home. I have one file server with a 1TB of data on redundant drives. I use nfs to share that out to a couple of application servers I use for development or just stuff I like to beat up on and I don't want playing with the apps to interfere with my clean, reliable primary server.

If you wanted some security, you could tunnel the nfs shares through stunnel. For business though, I use a SAN and would probably recommend against nfs because of performance (even though faster than cifs, it's still not as fast as iSCSI).

I don't want to give the impression that NFS sucks, because it doesn't, but you have to use the right tool for the right job. I just advised he look for something with more control and that is more flexible in case of network interruption. If he's rolling this out into a production SAN environment, he's definitely not going to want to deal with stale mounts on lots of machines. I like NFS for what it does and you're correct that it's faster UNIX to UNIX but it sounds like it wouldn't be a great fit for what he's trying to do, especially if he wants to have lots of machines access it and doesn't want to manually configure UID/GID pairs. Samba throughput wise isn't that different, the only extra latency is the Windows lookups and to be honest it's pretty negligible.

My comments were more from a 'make sure you research the ins and outs of what you're doing because each has its strengths and weaknesses' and I didn't want for him to be surprised by anything. Especially considering the questions asked in this thread, he needs a better understanding before blindly rolling it out.

 

[mfenn]

You mention that you have a "domain". I presume you're referring to an existing AD setup?

If you want, you can use Likewise Open to join your Linux boxes to your AD domain. This will give you a unified UID/GID space across your boxes, and make NFS permissions a lot simpler.

You can, of course, use LDAP or NIS to do the same thing, but why run 2 parallel directory services?

 

[Red Squirrel]

You mention that you have a "domain". I presume you're referring to an existing AD setup?

If you want, you can use Likewise Open to join your Linux boxes to your AD domain. This will give you a unified UID/GID space across your boxes, and make NFS permissions a lot simpler.

You can, of course, use LDAP or NIS to do the same thing, but why run 2 parallel directory services?

Hmm that's pretty cool. My DC is actually my main Linux box, think it would work with that? I never bothered adding my linux boxes to the domain as it's too complicated, but this might be worth looking into.

 

[mfenn]

Hmm that's pretty cool. My DC is actually my main Linux box, think it would work with that? I never bothered adding my linux boxes to the domain as it's too complicated, but this might be worth looking into.

Shouldn't matter who the DC is.