[afnog] Problem mounting a NAS device - FreeBSD
Geert Jan de Groot
GeertJan.deGroot at xs4all.nl
Thu May 10 22:06:46 UTC 2007
On Thu, 10 May 2007 17:50:52 +0200 "Ghislain Nkeramugaba" wrote:
> I am running FreeBSD 5.3 and would like to attach a NAS device.
> The command is:
> mount -t nfs -o username=xyz,password=abc A.B.C.D:/folder/subfolder
> I am getting an error :nfs: -o username=: option not supported
> How come it says not supported yet the man pages refer to the "-o" options?
> I am trying this on the command line, if it mounts it, i will edit the
> /etc/fstab file
I don't see '-o username=xyz,password=abc' mentioned in the
manual pages, archived on FreeBSD.org (I don't have a box to play with),
and frankly, I don't think what you want, can work.
NFS doesn't work like some of the other filesystems. It is a
kernel-mode to kernel-mode communication channel with a few limited
primitives, like open-file, read-block and write-block.
The context of usernames and passwords doesn't exist.
The only thing communicated is the numerical UNIX user ID -
the password files are best left in sync on both server and client!
Protection is typically only based on a. the ability to speak the
NFS protocol at all, and b. the ability to get a root NFS handle.
It's only the 2nd part that has any userland interaction.
Past that stage, there is no, repeat none, protection/mapping
of any kind.
First, are you sure the NAS box speaks NFS? These boxes typically
run pinguin inside, and have userland utilities that play chroot-like
games, username mapping and the like. This doesn't go well with a
low-level protocol like NFS, so the ones I am familiar with (Lacie),
don't even speak NFS.
I would use rpcinfo to check whether there is any RPC support on
your NAS box. If it isn't, then attempting an NFS mount is futile.
If it does support RPC, then it's just host (ip-address) based
security, and that's it. Note that none of this speaks about
usernames/passwords; the NFS mount protocol doesn't know what
to do with them.
If the NAS box does indeed speak NFS, and on my (NetBSD) box
it looks like this:
program version netid address service owner
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
100000 3 tcp 0.0.0.0.0.111 portmapper superuser
100000 2 tcp 0.0.0.0.0.111 portmapper superuser
100000 4 udp 0.0.0.0.0.111 portmapper superuser
100000 3 udp 0.0.0.0.0.111 portmapper superuser
100000 2 udp 0.0.0.0.0.111 portmapper superuser
100005 1 udp 0.0.0.0.3.248 mountd superuser
100005 3 udp 0.0.0.0.3.248 mountd superuser
100005 1 tcp 0.0.0.0.3.253 mountd superuser
100005 3 tcp 0.0.0.0.3.253 mountd superuser
100003 2 udp 0.0.0.0.8.1 nfs superuser
100003 3 udp 0.0.0.0.8.1 nfs superuser
100003 2 tcp 0.0.0.0.8.1 nfs superuser
100003 3 tcp 0.0.0.0.8.1 nfs superuser
(note that 8*256 + 1 = 2049, which is the NFS port)
The next thing is to make sure that mountd on the NAS box gives
your FreeBSD an NFS handle. This is controlled via /etc/exports,
(or probably a GUI interface on the NAS box that essentially does same),
and is the *only* security the protocol has.
If mountd hands out an NFS handle, the client uses it to "mount"
the server and things should work.
Lastly, note that NFS has a very, very weak protection model and
is only usable if you have full control over server and client.
You *must* filter TCP/UDP port 111, and TCP/UDP port 2049 for
anything outside your own administration.
None of these protocols have any business on the Internet-at-large,
they are intended for office environments where there is full control
over the machines involved. You are playing with fire.
This is long and you probably lost interest. That's fine,
but please re-read the previous paragraph about NFS security.
More information about the afnog