Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What I am trying to do is to have my openBSD client (OpenBSD 4.9) auto mount a Linux NFS file system (Scientific Linux 6.1). So far, I am not sure if it is configured correctly.

To get things out of the way, I am able to mount nfs manually:

# mount_nfs -T -3 192.168.15.100:/exports /mnt
# ls -la /mnt
total 52
drwxr-xr-x   7 root    wheel   4096 Oct  4 22:42 .
drwxr-xr-x  16 root    wheel    512 Nov 26 16:33 ..
drwxrwxr-x   5 _sndio  _sndio  4096 Oct 31 21:58 centos
drwxr-xr-x  15 root    wheel   4096 Nov  6 09:17 home
drwxr-xr-x   5 root    wheel   4096 Oct 31 21:27 sl
drwxr-xr-x   3 root    wheel   4096 Nov 19 16:02 sles
drwxr-xr-x  17 503     503     4096 Nov 10 17:37 users
# 

So connectivity is not an issue, as far as I can tell.

As per man page, the following is configured in /etc/amd/auto.home:

/defaults type:=nfs;sublink:=${key};opts:=rw,soft,intr,vers=3,proto=tcp
*         rhost:=192.168.15.100;rfs:=/exports

In turn, /etc/amd/master is configured as such:

# cat /etc/amd/master                                                                                                                                                                    
/exports amd.home

Upon reboot, I can it see mount, but curiously enough, instead of the hostname:

amd:24490                        0         0         0   100%    /exports

From what I understand, amd acts a little different from FreeBSD. Still, I tried to see if I it can automount.

Nope:

ksh: cd: /exports/users - Resource temporarily unavailable
# cd /exports/192.168.15.100/host/users
ksh: cd: /exports/192.168.15.100/host/users - Resource temporarily unavailable

A search in google doesn't help too much - it seems that automounting NFS with OpenBSD is not something that is usually done. Other than this, information is fairly sparse.

I can, of course, always mount is permanently, but I tend to be a bit anal on convention, so no for now. :)

Some direction would be appreciation.

(And oh, in case you are a wondering, I tried FreeBSD way of using amd and that hasn't worked out - although I wouldn't mind an explanation of the difference between how FreeBSD implements and how OpenBSD implements it)

UPDATE: After re-writing the map file several times, I got as far as actually communicating with the NFS server with this configuration:

/defaults type:=nfs;rhost:=kerberos.monzell.com;rfs:=/exports;\
          sublink:=${key};opts:=rw,nodev,nosuid,soft,intr,tcp,resvport
*         ${host}==${rhost};type:=nfs;fs:=${rfs};opts:=rw,nodev,nosuid,soft,intr,tcp,resvport

However, for some reason, it seems that amd will only default to NFS version 2 over udp:

# tcpdump dst kerberos
tcpdump: listening on pcn0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
20:38:28.558385 openbsd.monzell.com.856 > kerberos.monzell.com.sunrpc: udp 100
20:38:28.559154 openbsd.monzell.com.856 > kerberos.monzell.com.892: udp 96
20:38:30.592761 openbsd.monzell.com.856 > kerberos.monzell.com.nfsd: xid 0x22000000 (NFSv2) 40 null
20:38:33.558107 arp reply openbsd.monzell.com is-at 52:54:00:52:8f:66

I tried various options of forcing it to try to mount as nfsv3 such as:

/defaults type:=nfs;rhost:=kerberos.monzell.com;rfs:=/exports;\
          sublink:=${key};opts:=rw,nodev,nosuid,soft,intr,vers=3,proto=tcp,resvport
*         ${host}==${rhost};type:=nfs;fs:=${rfs};opts:=rw,nodev,nosuid,soft,intr,vers=3,proto=tcp,resvport

or:

/defaults type:=nfs;rhost:=kerberos.monzell.com;rfs:=/exports;\
          sublink:=${key};opts:=rw,nodev,nosuid,soft,intr,vers=-3,proto=tcp,resvport
*         ${host}==${rhost};type:=nfs;fs:=${rfs};opts:=rw,nodev,nosuid,soft,intr,vers=3,proto=tcp,resvport

Nothing yet still.

Curious enough, OpenBSD mounts defaults to version 3, so I am not sure why it would start with version 3 in amd. What would be the correct options to pass to automount?

EDIT: As I pointed out, I can point via fstab. For proof, here it is:

kerberos:/exports /mnt nfs rw,nodev,nosuid,tcp,soft,intr 1 1 
Filesystem        512-blocks      Used     Avail Capacity  Mounted on
/dev/wd0a             290396     89032    186848    32%    /
/dev/wd0k            3240316   1858940   1219364    60%    /home
/dev/wd0d             448956        12    426500     0%    /tmp
/dev/wd0f            1943196    903596    942444    49%    /usr
/dev/wd0g            1105820    346852    703680    33%    /usr/X11R6
/dev/wd0h            4387772    256560   3911824     6%    /usr/local
/dev/wd0j            2137436         4   2030564     0%    /usr/obj
/dev/wd0i            2137436         4   2030564     0%    /usr/src
/dev/wd0e             498940     18676    455320     4%    /var
amd:26660                  0         0         0   100%    /net
kerberos:/exports  103212280  66319088  31650312    68%    /mnt

As I noted, OpenBSD mounts via version 3 first, so I don't know why under amd, it would not mount via version 3 (tcp) and instead mount via version 2 with udp.

EDIT: As suggested, I attempted the following configurations:

defaults type:=nfs;fs:=${autodir}
  # autodir = -a parameter of amd call = amd_mnt in rc.conf = /tmp_mnt
  # Be careful with 'umount' and 'unmount' in the following.
remote type:=program;fs:=/mnt;\
        mount:="/sbin/mount_nfs kerberos.monzell.com:/exports/";\
        unmount:="/sbin/umount /mnt"

That returned

# cd /net/remote                                                                                                                                                                                 
usage:  [-23bcdilsTU] [-a maxreadahead] [-g maxgroups]
        [-I readdirsize] [-o options] [-R retrycnt] [-r readsize]
        [-t timeout] [-w writesize] [-x retrans] rhost:path node
ksh: cd: /net/remote - Operation not permitted

Then this:

defaults type:=nfs;fs:=${autodir}
  # autodir = -a parameter of amd call = amd_mnt in rc.conf = /tmp_mnt
  # Be careful with 'umount' and 'unmount' in the following.
remote type:=program;fs:=/mnt;\
        mount:="/sbin/mount nfs kerberos.monzell.com:/exports/";\
        unmount:="/sbin/umount /mnt"

Which returned this:

# cd /net/remote                                                                                                                                                                                 
nfs: realpath kerberos.monzell.com:/exports/: No such file or directory
ksh: cd: /net/remote - Operation not permitted

Nothing yet.

share|improve this question

6 Answers 6

regarding the type:=program mount/unmount commands, the infodoc for amd on OpenBSD mentions that the first element in the argument is the program to execute, and the second arg is what gets passed in as $0.

so iow, if i did

mount:="/sbin/mount_nfs -x10 -3 -dt600 -r32768 -w32768 -o rw,tcp.intr host:/path/${key} /local/${key}"

i ended up getting:

usage: -x10 [-23bcdilsTU] [-a maxreadahead] [-g maxgroups] [-I readdirsize] [-o options] [-R retrycnt] [-r readsize] [-t timeout] [-w writesize] [-x retrans] rhost:path node

putting 'mount_nfs' in there in front of the -x10 (and similar for the unmount prog) solved the syntax error for me, however i found the whole "mount to -a mount_point and then make symlinks" thing was not automatically handled in this case. i debated writing a wrapper script but instead ended up going with:

/defaults type:=nfs; jspiegel rhost:=NFS_HOST;rfs:=NFS_EXPORT_PATH/${key};opts:="rw,tcp,intr"

in my case, i am getting auto.home via NIS, and the syntax in it is specific to linux's nfs mount, so i'm doing a cronjob that does a yppoll on auto.home, and if the server has a newer one, i pull it down and basically run it through sed(1) a lot and spit out an auto.home.fixed file that i have amd read. not perfect, but the machine in question is just a YP client, not a slave, so nothing in the yp/Makefile is going to do me any good.

share|improve this answer
up vote 0 down vote accepted

Finally "figured" it out. What I did is to copy an existing FreeBSD map file to /etc/amd/amd.net as follows:

/defaults       type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
*               opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev

{autodir} is set to the default directory used by amd (which is apparently /tmp_mnt, while ${rhost} is the remote host as specified by the key (which looks for the host name either in DNS or in /etc/hosts file:

192.168.15.250          qnap    qnap.monzell.com

On top of that is the host directory.

Then I created a directory in the root as:

/etc/amd/master:

/host amd.net

Then I create a host directory under root. Afterwards, it works as expected.

$ df
Filesystem   512-blocks      Used     Avail Capacity  Mounted on
/dev/wd0a        290396     89088    186792    32%    /
/dev/wd0k       3240316   1858968   1219336    60%    /home
/dev/wd0d        448956        12    426500     0%    /tmp
/dev/wd0f       1943196    903596    942444    49%    /usr
/dev/wd0g       1105820    346852    703680    33%    /usr/X11R6
/dev/wd0h       4387772    256560   3911824     6%    /usr/local
/dev/wd0j       2137436         4   2030564     0%    /usr/obj
/dev/wd0i       2137436         4   2030564     0%    /usr/src
/dev/wd0e        498940     18656    455340     4%    /var
amd:9747              0         0         0   100%    /host
qnap:/Public 1916713232 642213152 1274500080    34%    /tmp_mnt/qnap/host/Public
qnap:/pub    1916713232 642213152 1274500080    34%    /tmp_mnt/qnap/host/pub
qnap:/users  1916713232 642213152 1274500080    34%    /tmp_mnt/qnap/host/users

It looks like most communication NFS needs to be through the host, which takes care of the remote mount via NFSv3/TCP. Any attempts to mount remotely via amd directly will default to udp,version 2.

Still don't really understand amd, but I got it working, which means I am mostly there. :)

share|improve this answer

I think your mount command in the last edits are wrong. Don't know a lot about BSD, but let's give it a try.

defaults type:=nfs;fs:=${autodir}
 # autodir = -a parameter of amd call = amd_mnt in rc.conf = /tmp_mnt
 # Be careful with 'umount' and 'unmount' in the following.
remote type:=program;fs:=/mnt;\
       mount:="/sbin/mount_nfs kerberos.monzell.com:/exports/";\
       unmount:="/sbin/umount /mnt"

That returned

# cd /net/remote                                                                                                                                                                                 
usage:  [-23bcdilsTU] [-a maxreadahead] [-g maxgroups]
        [-I readdirsize] [-o options] [-R retrycnt] [-r readsize]
        [-t timeout] [-w writesize] [-x retrans] rhost:path node
ksh: cd: /net/remote - Operation not permitted

As it gives you the usage output, parametes are wrong. In this case, the target dir is missing.

Then this: defaults type:=nfs;fs:=${autodir} # autodir = -a parameter of amd call = amd_mnt in rc.conf = /tmp_mnt # Be careful with 'umount' and 'unmount' in the following. remote type:=program;fs:=/mnt;\ mount:="/sbin/mount nfs kerberos.monzell.com:/exports/";\ unmount:="/sbin/umount /mnt" Which returned this:

# cd /net/remote                                                                                                                                                                                 
nfs: realpath kerberos.monzell.com:/exports/: No such file or directory
ksh: cd: /net/remote - Operation not permitted

You missed the -t in /sbin/mount -t nfs kerberos.monzell.com:/exports/.

I think it should work without program parameter, i.e without using the mount command directly. But I don't now amd...

share|improve this answer
    
The target directory is specified in "fs:=", as documented here (millstream.com/desktop.html), a linked suggested by fawltyserver. So, yes, in a sense, that is intentional - it was a work around, as it were. As I said before, though, it seems that there is NFS communications with the original configuration I had, so at this point AMD appears to work to a point. At this point, it is an issue of getting amd to mount with the correct NFS version and protocol. –  Rilindo Dec 6 '11 at 21:05

My understanding is that amd and fstab do not need to be treated as alternatives, amd should be put on top of the fstab configuration after you have got fstab working properly. This page explains how to automount CD and floppy drives using amd. It relates to an older version of OpenBSD, but is hopefully still relevant.

I do not fully understand your configuration, and have not configured NFS on OpenBSD, but you appear to be trying to put configuration that is best put into fstab into amd instead. Get it all working in fstab first then configure amd to use what you have done in fstab.

Hope that helps.

share|improve this answer
    
I updated my answer to make it clear that I have got working under fstab. –  Rilindo Dec 2 '11 at 3:55
    
The linked page uses type:=program and you are using type:=nfs. Would type:=program be worth trying instead? –  fawltyserver Dec 2 '11 at 10:13
1  
@Rilindo What I am trying to say is that there is no need for all that configuration to be put into amd. You can use the type:=program option in amd to invoke your working fstab. Like the linked page. Am I wrong? –  fawltyserver Dec 3 '11 at 14:41
    
I tried it a few days, but I only now got around to this page. The answer is no, not really. That said, I am not sure why I would need to use an external program, when it is clear there is NFS communication between the host with the previous configuration. I just not sure why it is defaulting to nfs2/udp and ignore my options I passed to it. –  Rilindo Dec 3 '11 at 15:15

Again: With OpenBSD, you don't turn to Google, you turn to the man pages.

So, read the man page like a Zen master.

Or, as mentioned in the amd man page, use: 'info amd'

The man page mentions logging, let us know if you get any amd or nfs related messages, and don't be afraid to share them with us.

Also, do check /tmp_mnt and /a

However, again from the man page: "A weird imagination is most useful to gain full advantage of all the features."

share|improve this answer

You probably don't need amd. I automount lots of NFS directories, I've never had a need for amd. With OpenBSD, you don't turn to Google, you turn to the man pages. See the fstab(5) man page, which has this example:

server:/export/ports /usr/ports nfs rw,nodev,nosuid,soft,intr 0 0

share|improve this answer
    
I actually did look at the man page for amd, (which I alluded to). Now if there is something I missed in the page, I would appreciate that somebody would point that out to me. As for fstab, I can mount the via fstab, but that's not the solution I want. The issue getting amd to automount a NFS server. It should work, from what I understand from the documentation. It is just not clear to me why it isn't right now. –  Rilindo Nov 26 '11 at 23:48
    
What is the size of your installation? How many clients are doing NFS mounts? What features of amd do you need, that regular fstab does not provide? It sounds like amd is just complexity you don't need. –  Alex Holst Nov 27 '11 at 10:40
    
I am not sure why that is exactly pertinent in the issue at the moment. I know how to mount via fstab, but that's not my goal - my goal is to setup automount on the openBSD client. I was able to do it on FreeBSD, on Centos, on Debian and on Ubuntu. Its only on openBSD that I have yet to get working. –  Rilindo Nov 27 '11 at 17:18
    
It's relevant because OpenBSD tries to be the exact opposite of complexity. Trying to use an automount daemon unless there's an actual need would count as unnecessary complexity. –  Alex Holst Nov 27 '11 at 19:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.