It's included in the latest Gnome with gvfs; basically gvfs-aware apps will use gvfs, but a filesystem is mounted under ~/.gvfs so that other apps can access the files as well.
Features:
authentification and encryption through ssh+sftp
user-mounted
Unix DAC semantic
Performance is good on a LAN (not that much of a hit compared to NFS), and it handles WAN connections quite well, even if the connection is a bit dodgy
no configuration required on the server, if you have an ssh account you're good to go
It's not in RHEL, but RHEL 5.4 has the fuse module in the kernel, you just need to install the sshfs bit.
I've used NFS since 2001 and still really like it. It behaves just like a local filesystem, and it's reliable if one of the servers goes away. There are some application compatability issues however. Don't run things like big databases on NFS. Also GNOME used to have problems but that seems to be mostly fixed by lockd and other locking methods.
This depends massively on whether you control and trust the network you're using. If you completely trust the network and have control over what machines are added to the network, then NFS and CIFS have little to separate them. The biggest problem is that if any of your users have root on a box that is an NFS client, there is little to stop them changing to another user and bypassing the access control you have on the NFS server. You can stop root, but setting root_squash, but that only applies to root. (enabling root_squash is still a great idea). The downside of CIFS is, while it prevents the permission problem, because it mounts a particular share as a particular user, only that user can access their files. Obviously, if alice mounts a CIFS share, and bob has root, bob can su to alice and access her files.
If you only trust some of the computers on your network, you might want to look into the extra protections that NFS4 gives you. This requires kerberos to authenticate hosts before they can mount partitions.
If you want to connect across a public network you don't trust, then you need something that has encryption. Either you can look at running CIFS or NFS over some sort of VPN (which may be the least complicated solution, or you look at something like ssffs, which uses ssh as a transport.
fuse-sshfs
It's included in the latest Gnome with gvfs; basically gvfs-aware apps will use gvfs, but a filesystem is mounted under ~/.gvfs so that other apps can access the files as well.
Features:
It's not in RHEL, but RHEL 5.4 has the fuse module in the kernel, you just need to install the sshfs bit.
I've used NFS since 2001 and still really like it. It behaves just like a local filesystem, and it's reliable if one of the servers goes away. There are some application compatability issues however. Don't run things like big databases on NFS. Also GNOME used to have problems but that seems to be mostly fixed by lockd and other locking methods.
This depends massively on whether you control and trust the network you're using. If you completely trust the network and have control over what machines are added to the network, then NFS and CIFS have little to separate them. The biggest problem is that if any of your users have root on a box that is an NFS client, there is little to stop them changing to another user and bypassing the access control you have on the NFS server. You can stop root, but setting root_squash, but that only applies to root. (enabling root_squash is still a great idea). The downside of CIFS is, while it prevents the permission problem, because it mounts a particular share as a particular user, only that user can access their files. Obviously, if alice mounts a CIFS share, and bob has root, bob can su to alice and access her files.
If you only trust some of the computers on your network, you might want to look into the extra protections that NFS4 gives you. This requires kerberos to authenticate hosts before they can mount partitions.
If you want to connect across a public network you don't trust, then you need something that has encryption. Either you can look at running CIFS or NFS over some sort of VPN (which may be the least complicated solution, or you look at something like ssffs, which uses ssh as a transport.