autofs config

[Harry Putnam]

,----
| NOTE: A similar post was accidently posted to gentoo list but was
| intended to be posted here
`----
Setup: Running Debian jessie-stable


I've never used autofs and am trying to get it setup.
Following the debian wiki and an Ubuntu howto.
Also this site:

http://www.linuxtechi.com/automount-nfs-share-in-linux-using-autofs/

I've installed the pkg:

aptitude search ^autofs|grep ^i
i autofs - kernel-based automounter for Linux


created mount point: mkdir /projects-nfs

I've edited /etc/auto.master by adding this line:

/projects-nfs /etc/auto.master.d/prj-nfs.autofs --timeout=180

Created the directory `mkdir /etc/auto.master.d'

created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in
auto.master):

d0 --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/d0
dv --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/dv

Those directories on that host are available.
They reside on an solaris (x86) host and set to be available to nfs.

They can be mounted manually:
mount -t nfs 2x:/projects/dv /nfs/dv

Checking /nfs/dv... I find it is mounted.

So umounting /nfs/dv
And starting autofs with:
/etc/init.d/autofs start

However when I chk status I get [asterisks added for clarity]:

/etc/init.d/autofs status
● autofs.service - LSB: Automounts filesystems on demand
Loaded: loaded (/etc/init.d/autofs)
Active: active (running) since Sun 2017-01-08 13:40:45 EST; 4s ago
Process: 3638 ExecStop=/etc/init.d/autofs stop (code=exited, status=0/SUCCESS)
Process: 3671 ExecStart=/etc/init.d/autofs start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/autofs.service
└─3676 /usr/sbin/automount --pid-file /var/run/autofs.pid

Jan 08 13:40:45 d0 systemd[1]: Starting LSB: Automounts filesystems on demand...
*** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near
[ d0 --fstype=nfs4,rw,soft,intr 191.168.1.42: ]
*** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near [ projects ]
Jan 08 13:40:45 d0 autofs[3671]: Starting automount....
Jan 08 13:40:45 d0 systemd[1]: Started LSB: Automounts filesystems on demand.

No way to tell what the syntax error is.
I thought it might be spaces instead of tabs so when back and made
sure the whitspaces are tabs.

The above sited URL shows the entries for map file are to include:

<Mount-Point> <Mount-Options> <Location_of_File System>
And gives the example:
db_backup -fstype=nfs,rw,soft,intr 192.168.1.21:/db_backup

I'm not seeing what the `syntax error' is in my file.

[Reco]

Hi.

On Sun, 08 Jan 2017 13:37:32 -0500
Harry Putnam <rea...@newsguy.com> wrote:

> I've edited /etc/auto.master by adding this line:
>
> /projects-nfs /etc/auto.master.d/prj-nfs.autofs --timeout=180

And it gone haywire from here.

Autofs has a concept of master map ( auto.master(5) ) which can contain
lines referring to either direct or indirect maps ( autofs(5) ).

/etc/auto.master.d is intended for extending master map, and the files
inside it should contain master map entries, not indirect ones like you
did below.

> Created the directory `mkdir /etc/auto.master.d'
>
> created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in
> auto.master):
>
> d0 --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/d0
> dv --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/dv

Note that it be simplified to:

* --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/&


Also please note that they give you /etc/auto.net just for your case
(i.e. mounting nfs).

> *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near
> [ d0 --fstype=nfs4,rw,soft,intr 191.168.1.42: ]
> *** Jan 08 13:40:45 d0 automount[3676]: syntax error in map near
> [ projects ]

So, what you need to do instead is:

# /etc/auto.master

/projects-nfs /etc/auto.nfs --timeout=180

# /etc/auto.nfs

d0 --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/d0
dv --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/dv

And since you're using Debian stable you might consider ditch autofs
altogether as well and use systemd automounting as described in [1].

Reco

[1] http://blog.tomecek.net/post/automount-with-systemd/

[Sven Hartge]

Reco <recov...@gmail.com> wrote:

> [1] http://blog.tomecek.net/post/automount-with-systemd/

Note: this only works with static mounts.

If you want to use any kind of automatic mapping you can't do this with
systemd.

Grüße,
S°

--
Sigmentation fault. Core dumped.

[Harry Putnam]

Reco <recov...@gmail.com> writes:

[...]

> And it gone haywire from here.

Hehe... thats a good description...

> Autofs has a concept of master map ( auto.master(5) ) which can contain
> lines referring to either direct or indirect maps ( autofs(5) ).
>
> /etc/auto.master.d is intended for extending master map, and the files
> inside it should contain master map entries, not indirect ones like you
> did below.

Thanks... and I got that all squared away.

[...]

Harry wrote

>> created /etc/auto.master.d/prj-nfs.autofs like so (as suggested in
>> auto.master):
>>
>> d0 --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/d0
>> dv --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/dv
>

Reco wrote:
> Note that it be simplified to:
>
> * --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/&

I created /etc/auto.nfs and tried that forumulation. Restarted
autofs. Nothing gets mounted under (now simplified to /projects in
auto.master) /projects when I do ls /projects/d0 or /projects/dv

There is a bit of a pause with `ls /projects/dv (or d0) but then I
get:
ls: cannot access /projects/dv: No such file or directory

To clarify my above comments:

root # grep -v '^#\|^$' /etc/auto.master
/projects /etc/auto.nfs --timeout=180
+dir:/etc/auto.master.d
+auto.master

root # grep -v '^#\|^$' /etc/auto.nfs
* --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/&

I also tried this:

root # grep -v '^#\|^$' /etc/auto.nfs

d0 --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/d0
dv --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/dv

A `ls /projects/dv' pauses maybe 10 seconds and returns:
ls: cannot access /projects/dv: No such file or directory

One question... am I supposed to create the directories
/projects/dv /projects/d0 ?

It appears from the instructions I've seen that .. no I am not to
create those dir... just /projects/. however, I did try it both ways
and can report that nothing gets mounted in either test.

> Also please note that they give you /etc/auto.net just for your case
> (i.e. mounting nfs).

Not sure what you mean by `give you'. Do you mean to use as is?
I tried:
root # grep -v '^#\|^$' /etc/auto.master
/projects /etc/auto.net --timeout=180 (Note: It now says `auto.net')
+dir:/etc/auto.master.d
+auto.master

Made sure auto.net is chmod 755

Changed (in auto.net)
opts="-fstype=nfs,hard,intr,nodev,nosuid"
#opts="-fstype=nfs4,hard,intr,nodev,nosuid,async"
To:
#opts="-fstype=nfs,hard,intr,nodev,nosuid"
opts="-fstype=nfs4,hard,intr,nodev,nosuid,async"

Restarted autofs
Again, nothing is mounted under /projects/
A `ls /projects/dv (or d0)' returns immediately with output:
ls: cannot access /projects/dv: No such file or directory

And once again .. to test nfs:

mount -t nfs 192.168.1.42:/projects/dv /nfs/dv
ls /nfs/dv (Yup... lots of files under here)

I'm not able to see what I am doing wrong...

[Reco]

Hi.

On Mon, 09 Jan 2017 08:14:51 -0500
Harry Putnam <rea...@newsguy.com> wrote:

> Reco wrote:
> > Note that it be simplified to:
> >
> > * --fstype=nfs4,rw,soft,intr 191.168.1.42:/projects/&
>
> I created /etc/auto.nfs and tried that forumulation. Restarted
> autofs. Nothing gets mounted under (now simplified to /projects in
> auto.master) /projects when I do ls /projects/d0 or /projects/dv
>
> There is a bit of a pause with `ls /projects/dv (or d0) but then I
> get:
> ls: cannot access /projects/dv: No such file or directory

Won't it be fun otherwise?

The good thing is - autofs is working as intended.
The bad thing is - mount is failing.

Which brings me to this:

1) What security option are you using (i.e. none, sys, krb5, etc)?
If unsure, please mount a share by hand and obtain mount options
from /proc/mounts.

2) If you're using kerberos, can autofs access krb5.conf and
krb5.keytab?

3) Stop autofs, start it like this:

/usr/sbin/automount -fd

Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C.

> One question... am I supposed to create the directories
> /projects/dv /projects/d0 ?
>
> It appears from the instructions I've seen that .. no I am not to
> create those dir... just /projects/. however, I did try it both ways
> and can report that nothing gets mounted in either test.

No, you definitely do not. Either autofs creates a directory for you, or
you're unable to mount it. Top-level directory *must* be created, but
you did it.

> > Also please note that they give you /etc/auto.net just for your case
> > (i.e. mounting nfs).
>
> Not sure what you mean by `give you'. Do you mean to use as is?
> I tried:
> root # grep -v '^#\|^$' /etc/auto.master
> /projects /etc/auto.net --timeout=180 (Note: It now says `auto.net')
> +dir:/etc/auto.master.d
> +auto.master

Should be something like this:

/projects program:/etc/auto.net --timeout=180

> Made sure auto.net is chmod 755

Yep, it's importanet.

> Changed (in auto.net)
> opts="-fstype=nfs,hard,intr,nodev,nosuid"
> #opts="-fstype=nfs4,hard,intr,nodev,nosuid,async"
> To:
> #opts="-fstype=nfs,hard,intr,nodev,nosuid"
> opts="-fstype=nfs4,hard,intr,nodev,nosuid,async"

A small nit. Do not use 'hard' mount option unless you absolutely need
it. It is painful, and it's by design. It has nothing to do with your
current problem, though. What you probably need is:

-fstype=nfs4,soft,intr,nodev,nosuid,async

Reco

[Harry Putnam]

Reco <recov...@gmail.com> writes:

[...]

> Won't it be fun otherwise?
>
> The good thing is - autofs is working as intended.
> The bad thing is - mount is failing.

,----
| NOTE: I've rearranged your post to put the next question and answer at
| the bottom of this reply
`----
[...] missing q and a

>> One question... am I supposed to create the directories
>> /projects/dv /projects/d0 ?
>>
>> It appears from the instructions I've seen that .. no I am not to
>> create those dir... just /projects/. however, I did try it both ways
>> and can report that nothing gets mounted in either test.
>
> No, you definitely do not. Either autofs creates a directory for you, or
> you're unable to mount it. Top-level directory *must* be created, but
> you did it.

Well at least I got that part right.

[...]

>> /projects /etc/auto.net --timeout=180 (Note: It now says `auto.net')
>> +dir:/etc/auto.master.d
>> +auto.master
>

Reco wrote

> Should be something like this:
>
> /projects program:/etc/auto.net --timeout=180

Ok, commented out the 2 lines that were uncommented by default

[...]

> A small nit. Do not use 'hard' mount option unless you absolutely need
> it. It is painful, and it's by design. It has nothing to do with your
> current problem, though. What you probably need is:
>
> -fstype=nfs4,soft,intr,nodev,nosuid,async

All right, good to know.

------- ------- ---=--- ------- -------

And now the question answer I moved:

Reco Wrote:
> Which brings me to this:
>
> 1) What security option are you using (i.e. none, sys, krb5, etc)?
> If unsure, please mount a share by hand and obtain mount options
> from /proc/mounts.

It appears to be sys (sec=sys)

192.168.1.42:/projects/dv /projects/dv nfs4 rw,relatime,vers=4.0,\
rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,\
timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.29,local_lock=none,\
^^^^^^^
addr=192.168.1.42 0 0

[...]

> 3) Stop autofs, start it like this:
>
> /usr/sbin/automount -fd
>
> Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C.

(below I marked with *** what might be a clue)
------- ------- ---=--- ------- -------
parse_init: parse(sun): init gathered global options: (null)
spawn_mount: mtab link detected, passing -n to mount
spawn_umount: mtab link detected, passing -n to mount
mounted indirect on /test with timeout 90, freq 23 seconds
st_ready: st_ready(): state = 0 path /test
handle_packet: type = 3
handle_packet_missing_indirect: token 47, name dv, request pid 11696
attempting to mount entry /test/dv
lookup_mount: lookup(file): looking up dv
lookup_mount: lookup(file): dv -> --fstype=nfs4,rw,soft,intr 191.168.1.42:/test
parse_mount: parse(sun): expanded entry: --fstype=nfs4,rw,soft,intr 191.168.1.42:/test
parse_mount: parse(sun): gathered options: -fstype=nfs4,rw,soft,intr
parse_mount: parse(sun): dequote("191.168.1.42:/test") -> 191.168.1.42:/test
parse_mount: parse(sun): core of entry: options=-fstype=nfs4,rw,soft,intr, loc=191.168.1.42:/test
sun_mount: parse(sun): mounting root /test, mountpoint dv, what 191.168.1.42:/test, fstype nfs, options -fstype=nfs4,rw,soft,intr
mount_mount: mount(nfs): root=/test name=dv what=191.168.1.42:/test, fstype=nfs, options=-fstype=nfs4,rw,soft,intr
mount_mount: mount(nfs): nfs options="-fstype=nfs4,rw,soft,intr", nobind=0, nosymlink=0, ro=0
get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 6 version 0x30
get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 17 version 0x30

*** mount(nfs): no hosts available

dev_ioctl_send_fail: token = 47
failed to mount /test/dv
handle_packet: type = 3
handle_packet_missing_indirect: token 48, name dv, request pid 11696
dev_ioctl_send_fail: token = 48
st_expire: state 1 path /test
expire_proc: exp_proc = 140662262839040 path /test
expire_cleanup: got thid 140662262839040 path /test stat 0
expire_cleanup: sigchld: exp 140662262839040 finished, switching from 2 to 1
st_ready: st_ready(): state = 2 path /test
st_expire: state 1 path /test
expire_proc: exp_proc = 140662262839040 path /test
expire_cleanup: got thid 140662262839040 path /test stat 0
expire_cleanup: sigchld: exp 140662262839040 finished, switching from 2 to 1
st_ready: st_ready(): state = 2 path /test
[...]
------- ------- ---=--- ------- -------

As I mentioned in the OP:
The host involved is a solaris x86 host. The file systems set for
nfs availability are not put into an /etc/exports type setup.

The way it is done on solaris with the zfs file system... is during
the creation of a file system with `zfs create'

One usees an option (-o) that looks like:

zfs create -o sharenfs=on -o sharesmb=on somezpool/some/path

So in the case above nfs (and smb access) will be turned on.

So maybe that has something to do with the problem...

But then again, maybe not. Because as I have demonstrated, the share
is readily recognized by this Debian host in a manual nfs mount.

[Reco]

Hi.

On Mon, Jan 09, 2017 at 06:48:43PM -0500, Harry Putnam wrote:
> Reco Wrote:
> > Which brings me to this:
> >
> > 1) What security option are you using (i.e. none, sys, krb5, etc)?
> > If unsure, please mount a share by hand and obtain mount options
> > from /proc/mounts.
>
> It appears to be sys (sec=sys)
>
> 192.168.1.42:/projects/dv /projects/dv nfs4 rw,relatime,vers=4.0,\
> rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,\
> timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.29,local_lock=none,\
> ^^^^^^^
> addr=192.168.1.42 0 0

Ok, that simplifies things somewhat. So it's tcp-over-ipv4 type of NFS4
without any security worth mentioning.

> > 3) Stop autofs, start it like this:
> >
> > /usr/sbin/automount -fd
> >
> > Mount a filesystem. Watch the debug output. Terminate it with Ctrl+C.
>
> (below I marked with *** what might be a clue)

You missed it by two lines ☺:

> get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 6 version 0x30
> get_nfs_info: called with host 191.168.1.42(191.168.1.42) proto 17 version 0x30
>
> *** mount(nfs): no hosts available

To workaround #828217 please comment out the line with '-host' in
/etc/auto.master.

> As I mentioned in the OP:
> The host involved is a solaris x86 host. The file systems set for
> nfs availability are not put into an /etc/exports type setup.

That's what they want you to beleive. Please check out
/etc/dfs/sharetab on NFS server.

> The way it is done on solaris with the zfs file system... is during
> the creation of a file system with `zfs create'

One of the ways of doing it, certainly not the most easiest one.
share(1M) is decade older at least and thousand times easier to use.

> So maybe that has something to do with the problem...

Hardly. The way you're doing on Solaris it you provide NFS shares to
everyone and their dog in read-write mode with sec=sys by NFS versions
ranging from two to four. At least these are defaults starting with
Solaris 10.

The thing that's broken here is autofs, not NFS implementation.

Reco

[Harry Putnam]

Reco <recov...@gmail.com> writes:

> To workaround #828217 please comment out the line with '-host' in
> /etc/auto.master.

Just wanted to get back to you right away about this part. Still
looking into the other things you mentioned.

The `-hosts' line in auto.master has been commented out from the start.

Must be shipped with autofs that way, as I did not do it.

So then apparently it is not #828217 at the bottom of this. Or at
least not because of `net -hosts' being in play.

[Reco]

Ok, let's simplify things then.

# /etc/auto.master (verbatim):

/projects-nfs /etc/auto.prj-nfs --timeout=180

# /etc/auto.prj-nfs (again, verbatim, and it's one line):

dv -fstype=nfs4,rw,soft,intr,proto=tcp,sec=sys
2x:/projects/dv


Please note that it's tabulation everywhere, not spaces.


And please post full debug output of autofs somewhere.

Reco

[Harry Putnam]

Reco <recov...@gmail.com> writes:

[...]

Harry wrote:
>> So maybe that has something to do with the problem...

Reco replied:

> Hardly. The way you're doing on Solaris it you provide NFS shares to
> everyone and their dog in read-write mode with sec=sys by NFS versions
> ranging from two to four. At least these are defaults starting with
> Solaris 10.
>
> The thing that's broken here is autofs, not NFS implementation.

I finally got around to trying the auto.net file you mentioned in your
first reply in this thread.

I still cannot read it and understand what it does but I may have some
good news to report.

Still unable to mount the shares I'm after `d0' and `dv' but, those
fail still with auto.master like:
/prj /etc/auto.net --timeout=90

The good news is other shares in that same SOLARIS:/projects can be
mounted as expected (see attached automount -fg output)

ls /prj/d0 or ls /prj/dv both fail. However another share on that
same setup on the solaris host `gv' and 2x comes up as expected.

So ls /prj/gv after a pause shows /prj/gv/merb/<many file here>

If I cd in there /prj/gv/merb as plain user reader I can:
touch file; rm file and etc.

However, all those directories exist at SOLARIS-HOST/projects/*
All have the same permissions set, all are zfs fs with sharenfs=on

>From solaris host:

ls -al projects
total 17
drwxrwxrwx+ 9 reader nfsu 10 Jan 10 12:34 .
drwxrwxrwx+ 2 root sys 3 Jan 8 01:48 .$EXTEND
drwxr-xr-x 38 root staff 43 Jan 10 11:20 ..
drwxrwxrwx+ 8 reader nfsu 10 Nov 12 10:11 2x
drwxrwxrwx+ 4 reader nfsu 7 Sep 29 2014 adm
drwxrwxrwx+ 4 reader nfsu 5 Jan 10 01:57 d0
drwxrwsrwx+ 26 reader nfsu 31 Jan 10 00:49 dv
drwxrwxrwx+ 18 reader nfsu 22 Jan 12 2015 gv
drwxrwxrwx+ 2 reader nfsu 3 Feb 9 2015 prj-fossil
-rwxrwxrwx+ 1 reader nfsu 1349 Jan 27 2015 srpscr

You may notice output about /projects/reader in the attached
automounter output but it has been since deleted from
SOLARIS:/projects

Also notice the odd looking permissions. A result of:

/bin/chmod -R A=everyone@:full_set:fd:allow /projects

See home sharenfs is set the same all around
>From Solaris:/projects/

for ii in 2x d0 dv gv; do zfs get sharenfs rpool/projects/$ii; done
NAME PROPERTY VALUE SOURCE
rpool/projects/2x sharenfs on local
NAME PROPERTY VALUE SOURCE
rpool/projects/d0 sharenfs on local
NAME PROPERTY VALUE SOURCE
rpool/projects/dv sharenfs on local
NAME PROPERTY VALUE SOURCE
rpool/projects/gv sharenfs on local

So still having a time seeing why thos specific shares cannot be
mounted.

[Reco]

Hi.

On Tue, 10 Jan 2017 12:50:44 -0500
Harry Putnam <rea...@newsguy.com> wrote:

> I finally got around to trying the auto.net file you mentioned in your
> first reply in this thread.
>
> I still cannot read it and understand what it does but I may have some
> good news to report.

The idea is that auto.net takes top-level directory (/prj in your case)
as a place to mount. Then it takes second-level directory as server
name and invokes 'showmount -e' on that server. Third-level (and lower)
directory should be a share name on that server.

So,

> Still unable to mount the shares I'm after `d0' and `dv' but, those
> fail still with auto.master like:
> /prj /etc/auto.net --timeout=90

That part of configuration is correct.

> ls /prj/d0 or ls /prj/dv both fail. However another share on that
> same setup on the solaris host `gv' and 2x comes up as expected.

You lost me here. If 'd0' and 'dv' are share names, you should use
auto.net like this:

cd /prj/<server_name>/d0
cd /prj/<server_name>/dv

If d0 and dv are host names - poke them with 'showmount -e' first, and
use them like this:

cd /prj/d0/<share_name>
cd /prj/dv/<share_name>

> So ls /prj/gv after a pause shows /prj/gv/merb/<many file here>

Therefore 'gv' is a host name and 'merb' is a share on that host.
Assuming you're using stock auto.net.
Debug autofs output confirms this:

update_offset_entry: parse(sun): updated multi-mount offset /merb ->
-fstype=nfs4,soft,intr,nodev,nosuid,async gv:/merb

Reco

[Harry Putnam]

Reco <recov...@gmail.com> writes:

[...]

>> ls /prj/d0 or ls /prj/dv both fail. However another share on that
>> same setup on the solaris host `gv' and 2x comes up as expected.
>
> You lost me here. If 'd0' and 'dv' are share names, you should use
> auto.net like this:

This problem is solved with your previous post. Here is how

All this time my map file said dv --type[...] 2x:/projects/dv
instead of: dv -type[...] [...]
I had two dashes instead of one.

When copying the part you specified as being verbatim ... I finally
saw my mistake

I'm really sorry I jerked you around so much. Now that I got the
right formulation I notice that `ls /projects-nfs/dv' mounts so fast
that the ls displays instantly.

I didn't post the debug data... since it was a fool mistake on my
part.

You've been very patient. Thank you.

>
> cd /prj/<server_name>/d0
> cd /prj/<server_name>/dv
>
> If d0 and dv are host names - poke them with 'showmount -e' first, and
> use them like this:

Sorry for that confusion too. No they are not host names in this
usage. They are host names on my lan but on the server that is serving
these shares (Solaris host 2x) they are share names.

[...]

>> So ls /prj/gv after a pause shows /prj/gv/merb/<many file here>
>
> Therefore 'gv' is a host name and 'merb' is a share on that host.
> Assuming you're using stock auto.net.
> Debug autofs output confirms this:

Egad... sorry I wrote it all wrong. I should have said:

ls /prj/gv
merb

`gv' is a share name on host 2x. and merb is a directory under that
share.
So on host 2x:
ls /projects/gv/
merb

And on host DEBIAN `ls /prj/gv
merb
I wrote it wrong and thoroughly confused things. When I meant to show
that it some shares were mounted as expected

2 strikes against me...

I hope to be more careful in any more posting on this list.

[Reco]

Hi.

On Tue, 10 Jan 2017 19:32:54 -0500
Harry Putnam <rea...@newsguy.com> wrote:

> Reco <recov...@gmail.com> writes:
>
> [...]
>
> >> ls /prj/d0 or ls /prj/dv both fail. However another share on that
> >> same setup on the solaris host `gv' and 2x comes up as expected.
> >
> > You lost me here. If 'd0' and 'dv' are share names, you should use
> > auto.net like this:
>
> This problem is solved with your previous post. Here is how
>
> All this time my map file said dv --type[...] 2x:/projects/dv
> instead of: dv -type[...] [...]
> I had two dashes instead of one.
>
> When copying the part you specified as being verbatim ... I finally
> saw my mistake
>
> I'm really sorry I jerked you around so much. Now that I got the
> right formulation I notice that `ls /projects-nfs/dv' mounts so fast
> that the ls displays instantly.
>
> I didn't post the debug data... since it was a fool mistake on my
> part.
>
> You've been very patient. Thank you.

You're welcome.

Reco