Not needing authentication at time of connection does enable boot time mounting for some interesting setups but, how is security managed?
- WorkA with username:username is the client system.
- ServB with username:"users" is the NFS server with share "shared".
Group "users" does not exist on WorkA however all users on ServB are members of a common "users" group. The share "shared" gives group "users" read/write access.
How is the NFS share going to write files as username:"users" or what default user:group will it use locally for remote client connections?
Discussion on:
View:
Show:
Usually kerberos is added to the mix. There are a number of tricks you can use though.
Honestly, I only use NFS for exports that don't need any authentication though. I've tested the protocols pretty exensively and Samba, while it does give up some performance when you're using it between unix boxes, it really doesn't give up enough to make adding layers on top of NFS worth fooling with any more. That's just my experience though. I'd love to hear differing opinions.
Honestly, I only use NFS for exports that don't need any authentication though. I've tested the protocols pretty exensively and Samba, while it does give up some performance when you're using it between unix boxes, it really doesn't give up enough to make adding layers on top of NFS worth fooling with any more. That's just my experience though. I'd love to hear differing opinions.
So your best bet is to have no security or have an LDAP centralizing user accounts. Good to know.
I was looking at it for a home NAS box setup between three OS except that NFS conflicts with the Harden packages in Debian.
still, I'd love to get or significantly reduce the use of Samba.
I was looking at it for a home NAS box setup between three OS except that NFS conflicts with the Harden packages in Debian.
still, I'd love to get or significantly reduce the use of Samba.
It doesn't help NFS's basic problem.
Client....
"I'm user 1000, give me access to the export user 1000 has access to."
Server....
"Done."
Don't use plain old NFS in insecure environments. There are a lot of ways to fix that but "out-of-the-box" it is an insecure protocol.
Client....
"I'm user 1000, give me access to the export user 1000 has access to."
Server....
"Done."
Don't use plain old NFS in insecure environments. There are a lot of ways to fix that but "out-of-the-box" it is an insecure protocol.
A future tip addresses using NFS with kerberos. And for a kerberized environment, it works really well (I wouldn't necessarily go through the hassle of setting up kerberos just for a secure NFS). There are other non-kerberos security options for NFSv4 as well (but I've not played with those yet).
And you're right... NFS, out of the box, is about as secure as anonymous FTP. Don't hand out important exports with rw access; make them ro and enjoy the speed and convenience (coupled with automounting, it works awesome).
And you're right... NFS, out of the box, is about as secure as anonymous FTP. Don't hand out important exports with rw access; make them ro and enjoy the speed and convenience (coupled with automounting, it works awesome).
In this case, I'm looking at a family NAS box shared between at least three OS platforms. I was considering going with native prots; osX uses it's, Windows uses CIFS/Samba, *nix uses NFS. The outcome seems to be CIFS (I hope samba4 turns up in Debian 6 soon).
On the server side, the NAS would have to account for users which means authentication pulling NFS and Rsync off the list.
On the client side, Debian throwing a warning over NFS conflicting with the security Harden packages keeps it off the list. I don't like adding things into my systems let alone specifically listed insecure things.
On the server side, the NAS would have to account for users which means authentication pulling NFS and Rsync off the list.
On the client side, Debian throwing a warning over NFS conflicting with the security Harden packages keeps it off the list. I don't like adding things into my systems let alone specifically listed insecure things.
...a Windows box in the mix, and a reasonable one even if there's not.
There is a unix tools for windows free program that will let you use nfs on a windows box.
NFS is faster than samba...but not by much. NFS is much simpler if you're on a completely trusted network. Your house will probably fall into that category. Other examples would be lock-and-key, isolated networks in the datacenter.
Of course...iscsi targets are even faster still, assuming we're talking gb connections with all the protocols. I digress though.
There is a unix tools for windows free program that will let you use nfs on a windows box.
NFS is faster than samba...but not by much. NFS is much simpler if you're on a completely trusted network. Your house will probably fall into that category. Other examples would be lock-and-key, isolated networks in the datacenter.
Of course...iscsi targets are even faster still, assuming we're talking gb connections with all the protocols. I digress though.
Network file systems may work fine on desktop machines which are (usually, in my experience) either On or Off. But laptops and other mobile devices often have their networking go up and down, they get put into sleep/hibernate, and they're often not at the same location all the time (meaning the connection may fail, possibly after waking from sleep).
I've been looking for a good network file system which can overcome these standard behaviours; is the long-standing NFS my solution? I've tried with SSHFS which seems to hang far too often after sleep; scripting the connect/disconnect doesn't work out; AutoFS+SSHFS+Avahi hasn't worked for me... this seems like a pretty big issue that should have a solution but I've not found it. Suggestions? I'm running Debian Testing, 2.6.32...
I've been looking for a good network file system which can overcome these standard behaviours; is the long-standing NFS my solution? I've tried with SSHFS which seems to hang far too often after sleep; scripting the connect/disconnect doesn't work out; AutoFS+SSHFS+Avahi hasn't worked for me... this seems like a pretty big issue that should have a solution but I've not found it. Suggestions? I'm running Debian Testing, 2.6.32...
... and it works well on my notebook and netbook computers. One down side is that sshfs is slower than NFS. And (re)connecting can take several (5 to 10) seconds.
Too much typing, I wonder why MS Windows is the most adopted OS in the world with "there is a GUI for that..."
But the whole article looks geared to Nix administrators. Not for average joe.
No, you're right... the setup isn't necessarily easy (well, yeah, it kinda is, but that's not what the implication is). _Using_ NFS is easy, really easy. Using it is easy... setting it up... your mileage may vary. But note where the word "easy" appears in the tip title. =)
I don't know much about IPv6, especially how to make addresses with it, but v4 was specified in the config files. What if you are v6?
Given how other packages have handled IPv4 and IPv6 (iptables for example), I'm guessing the only change in the config file will be the IPv6 hex instead of IPv4 four-threes.
If you want NFS share management through a GUI utility, you can certainly go get the app for that. If I remember correctly, Mandriva will have a GUI app included in the Draketools all "control panel" like.
Regardless of OS though, typing is so much faster for this stuff. Mount on *nix based systems. Net or win+r on Windows based systems.
.. But, don't let any of that get in the way of taking a cheap shot at your own ignorance.
Regardless of OS though, typing is so much faster for this stuff. Mount on *nix based systems. Net or win+r on Windows based systems.
.. But, don't let any of that get in the way of taking a cheap shot at your own ignorance.
If you are not interested in expanding your technical knowledge there are plenty of sites for sewing, knitting, cooking, or if these are still too technical for you there are plenty of forums that deal with gossip, entertainment news (gossip again). You may find these more suitable for you.
I think it's fairly important to point out that in /etc/exports there cannot be any space between the clients string and the bracketed options. Leaving a space or tab is a very common mistake, which completely changes the meaning of a line.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle

































