best way for user-specific access to nfs

[petersk]

I think I set up nfs on 9.04 correctly, but unfortunately, my wife's username is different on her mac than on my ubuntu machine. I think that's why when I try to mount the nfs disk, it asks for a password, but no username (and thus I don't have the right password).
What's the BEST way to still have user authentication but allow access to her username on the mac. I'm thinking 1 of these three might do it:
1) add a user with the correct permission that has a username that matches her mac username with the same passwd.
or
2) figure out how to specify user when mounting an nfs drive (the internet and this forum seems to indicate this is not possible
or
3) make a setting in /etc/exports that somehow maps her imac username to the linux UID.

Does anyone have any suggestions on the best way? I'd prefer NOT to do 1, but if it's the best way, then so be it.

Kurt

[vinnywright]

Re: best way for user-specific access to nfs

have a look hear

http://mostlylinux.wordpress.com/network/nfshowto/

VINNY

[petersk]

Re: best way for user-specific access to nfs

Good tutorial, but it doesn't seem to work (at least connecting a mac to kubuntu). Here's my settings and tries:
[I should note that I left both /etc/hosts.allow and hosts.deny empty, which should allow everything on the server.]

on the imac (ip address 192.168.1.90):

sudo mount -t nfs 192.168.1.87:/mnt/bigdrive ./backup/
Password:
Cannot MNT RPC: RPC: Remote system error - Operation timed out
Cannot MNT RPC: RPC: Remote system error - Operation timed out
mount_nfs: can't access /mnt/bigdrive: Permission denied

Settings on Kubuntu (server: 192.168.1.87):

cat /etc/exports
/mnt/bigdrive 192.168.1.90(rw,all_squash,sync,no_subtree_check,anonuid=1001,anongid=100,insecure) 192.168.1.88(rw,sync,no_subtree_check)

note I tried a number of variations, including just

cat /etc/exports
/mnt/bigdrive 192.168.1.90(rw,sync,no_subtree_check)

but got same error.

On the server, the firewall settings are (opened the ports found on a different blog: 32771? 111? and 2049?):

sudo ufw status
Status: active

To             Action From
--             ------ ----
22             ALLOW  Anywhere
80             ALLOW  Anywhere
123            ALLOW  Anywhere
137            ALLOW  Anywhere
138            ALLOW  Anywhere
139            ALLOW  Anywhere
389            ALLOW  Anywhere
445            ALLOW  Anywhere
631            ALLOW  Anywhere
7000            ALLOW  Anywhere
7001            ALLOW  Anywhere
56596           ALLOW  Anywhere
760            ALLOW  Anywhere
761            ALLOW  Anywhere
443            ALLOW  Anywhere
5080            ALLOW  Anywhere
53             ALLOW  Anywhere
32771           ALLOW  Anywhere
111            ALLOW  Anywhere
2049            ALLOW  Anywhere

do I need to open any ports on the imac? The same ones?
32771? 111? and 2049?
I turn off the imac firewall and that didn't seem to help.

I also found this (which didn't work):
http://fastessen.blogspot.com/2009/0...on-mac-os.html
and this for ports to open:
http://www.ubuntugeek.com/nfs-server...in-ubuntu.html
http://www.cyberciti.biz/faq/centos-...-server-ports/

Note, when I do a:

$sudo showmount --exports
Export list for odin:
/mnt/bigdrive 192.168.1.90

which looks right.
Kurt

[Snowhog]

Re: best way for user-specific access to nfs

Have to ask: Did you follow the howto exactly?

[petersk]

Re: best way for user-specific access to nfs

pretty much, except modifying the hosts.allow and hosts.deny -- since leaving both with nothing in them should allow everything.

[Snowhog]

Re: best way for user-specific access to nfs

That's a big assumption. Have you tried putting the entries within each as instructed in the howto?

[Ole Juul]

Re: best way for user-specific access to nfs

That's a big assumption.

Indeed. From my reading, theoretically if the hosts.deny and hosts.allow files don't exist then the access control will be turned off at that point. If you left the files as they were then the default used to be that all will be denied. Use of the files is supposedly optional and I see that recent versions of Ubuntu don't use them. Still, specific programs can have their own requirements and that could be happening here.

[Detonate]

Re: best way for user-specific access to nfs

My hosts.allow looks like this.

portmap: 192.168.1.10 192.168.1.16
lockd: 192.168.1.10 192.168.1.16
rquotad: 192.168.1.10 192.168.1.16
mountd: 192.168.1.10 192.168.1.16
statd: 192.168.1.10 192.168.1.16
nfsd: 192.168.1.10 192.168.1.16

My hosts.deny file looks like this.

ALL: ALL

I don't have a Mac, but this works perfectly for me on my Ubuntu network. 192.168.1.10 is the server, 192.168.1.16 is the client.

[petersk]

Re: best way for user-specific access to nfs

As for the hosts.allow; unless the man page is wrong; I don't see what "assumption" I'm making... and certainly don't see it as "wrong":

I think the key is: "Otherwise, access will be granted." I see what you're saying where it says "thus, access control can be turned off," but to me that means that access control is turned off giving free access.

NAME
    hosts_access - format of host access control files

DESCRIPTION
    This manual page describes a simple access control language that is
    based on client (host name/address, user name), and server (process
    name, host name/address) patterns. Examples are given at the end. The impatient reader is encouraged to skip to the EXAMPLES section for a
    quick introduction.

    The extended version of the access control language is described in the
    hosts_options(5) document. Note that this language supersedes the meaning of shell_command as documented below.

    In the following text, daemon is the process name of a network daemon
    process, and client is the name and/or address of a host requesting
    service. Network daemon process names are specified in the inetd conâ
    figuration file.

ACCESS CONTROL FILES
    The access control software consults two files. The search stops at the
    first match:

    -   Access will be granted when a (daemon,client) pair matches an
       entry in the /etc/hosts.allow file.

    -   Otherwise, access will be denied when a (daemon,client) pair
       matches an entry in the /etc/hosts.deny file.

    -   Otherwise, access will be granted.

    A non-existing access control file is treated as if it were an empty
    file. Thus, access control can be turned off by providing no access
    control files.

In general, it seems that as long as someone does NOT add anything to hosts.deny, then access should be granted to everything.

This all being said, since my Kubuntu machine seems to be supplying the network nfs by its response (above response to showmounts), I think the problem might be on the imac side. I don't see why, at all, you're adding the ALL: ALL to your hosts.deny. That seems to just make things more restrictive.

But... maybe you're right and something needs the settings, so I'll try them tonight for kicks.

[Detonate]

Re: best way for user-specific access to nfs

It reads the hosts.allow file first, if the host trying to access is there, it allows it. If it is not there it reads the hosts.deny file, and if it is found there it denies it. By putting ALL: ALL in the hosts.deny file, I am denying access to any IP not found in the hosts.allow file. This is done for security.

[Ole Juul]

Re: best way for user-specific access to nfs

@Detonate: I believe the use of those files is actually deprecated for Ubuntu.

[Detonate]

Re: best way for user-specific access to nfs

Yes, you don't have to use these files, but it adds an extra level of security.