NetBSD Problem Report #60493
From www@netbsd.org Thu Jul 23 21:44:15 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "YR2" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 414181A923B
for <gnats-bugs@gnats.NetBSD.org>; Thu, 23 Jul 2026 21:44:15 +0000 (UTC)
Message-Id: <20260723214414.75FA51A923C@mollari.NetBSD.org>
Date: Thu, 23 Jul 2026 21:44:14 +0000 (UTC)
From: sjg@crufty.net
Reply-To: sjg@crufty.net
To: gnats-bugs@NetBSD.org
Subject: autofs does not handle chroot
X-Send-Pr-Version: www-1.0
X-From4GNATS: "sjg@crufty.net via gnats" <gnats-admin@NetBSD.org>
>Number: 60493
>Category: bin
>Synopsis: autofs does not handle chroot
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: needs-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jul 23 21:45:01 +0000 2026
>Closed-Date:
>Last-Modified: Thu Aug 20 20:26:09 +0000 2026
>Originator: Simon Gerraty
>Release: 11.0
>Organization:
NetBSD
>Environment:
NetBSD bad.crufty.net 11.0_RC6 NetBSD 11.0_RC6 (GENERIC) #0: Tue Jul 7 15:10:39 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
This machine is using the setup described in https://wiki.netbsd.org/root_on_zfs/
Which is working fine. However when I setup autofs with
grep homes /etc/auto_master /etc/autofs/homes
/etc/auto_master:/homes /etc/autofs/homes
/etc/autofs/homes:* beast:/homes/&
and attempt to trigger a mount, it fails. Logging
Jul 22 16:04:54 bad automountd[943]: map /etc/autofs/homes does not contain key for "/altroot/homes/"; failing mount
ie. it is using the realpath of /homes/ rather than that valid from the chroot:
# mount /dev/dk1 /mnt
# grep zfs /mnt/etc/fstab
rpool/ROOT /altroot zfs rw
#
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Simon Gerraty <sjg@crufty.net>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/60493: autofs does not handle chroot
Date: Fri, 24 Jul 2026 03:45:00 +0000
This is a multi-part message in MIME format.
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP
Would you like to try the attached patch?
(Warning: totally untested; I have only verified it builds.)
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP
Content-Type: text/plain; charset="ISO-8859-1"; name="pr60493-autofschroot"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr60493-autofschroot.patch"
# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1784864508 0
# Fri Jul 24 03:41:48 2026 +0000
# Branch trunk
# Node ID 195a46d49d734f1334b6e99c472d6d12173d98c9
# Parent f75c5d43d5f2deed5b47bb74589a480ad6b7cd66
# EXP-Topic riastradh-pr60493-autofschroot
WIP: autofs: Support running inside a chroot.
PR kern/60493: autofs does not handle chroot
diff -r f75c5d43d5f2 -r 195a46d49d73 sys/fs/autofs/autofs.c
--- a/sys/fs/autofs/autofs.c Thu Jul 23 22:07:04 2026 +0000
+++ b/sys/fs/autofs/autofs.c Fri Jul 24 03:41:48 2026 +0000
@@ -75,6 +75,7 @@
#include "ioconf.h"
=20
#include <sys/atomic.h>
+#include <sys/filedesc.h>
#include <sys/queue.h>
#include <sys/signalvar.h>
=20
@@ -451,16 +452,58 @@ autofs_trigger(struct autofs_node *anp,=20
static int
autofs_ioctl_request(struct autofs_daemon_request *adr)
{
+ struct lwp *l =3D curlwp;
+ struct proc *p =3D curproc;
+ struct cwdinfo *cwdi =3D p->p_cwdi;
struct autofs_request *ar;
+ char *chrootpathbuf =3D NULL, *chrootpath =3D NULL;
+ size_t chrootpathlen =3D 0;
+ const char *path;
+ int error;
=20
+ /*
+ * If we're chrooted, find the prefix to match in requests and
+ * strip off.
+ *
+ * If we're not chrooted, don't bother with any of it: no need
+ * to allocate a pathbuf and compute getcwd(). If another
+ * thread chroots while we're working, tough.
+ */
+ if (atomic_load_relaxed(&cwdi->cwdi_rdir) !=3D NULL) {
+ chrootpathbuf =3D PNBUF_GET();
+
+ rw_enter(&cwdi->cwdi_lock, RW_READER);
+ error =3D getcwd_common(cwdi->cwdi_rdir, rootvnode, &chrootpath,
+ chrootpathbuf, MAXPATHLEN/2, 0, l);
+ rw_exit(&cwdi->cwdi_lock);
+ if (error)
+ goto out;
+ chrootpathlen =3D strlen(chrootpath);
+ }
+
+ /*
+ * Wait until there is a request that is:
+ *
+ * (a) not done,
+ * (b) not in progress by another thread,
+ * (c) if we're chrooted, within our chroot.
+ *
+ * Once we have one, mark it in progress so other threads don't
+ * take it.
+ */
mutex_enter(&autofs_softc->sc_lock);
for (;;) {
- int error;
TAILQ_FOREACH(ar, &autofs_softc->sc_requests, ar_next) {
if (ar->ar_done)
continue;
if (ar->ar_in_progress)
continue;
+ if (chrootpathlen > 1 &&
+ (strncmp(ar->ar_path, chrootpath, chrootpathlen)
+ !=3D 0 ||
+ (ar->ar_path[chrootpathlen] !=3D '/' &&
+ ar->ar_path[chrootpathlen] !=3D '\0')))
+ continue;
break;
}
=20
@@ -478,9 +521,27 @@ autofs_ioctl_request(struct autofs_daemo
ar->ar_in_progress =3D true;
mutex_exit(&autofs_softc->sc_lock);
=20
+ /*
+ * If we're chrooted, strip the chroot prefix off ar->ar_path.
+ * Otherwise, just use ar->ar_path as is for the adr->adr_path
+ * we return to userland.
+ */
+ if (chrootpathlen > 1) {
+ KASSERT(strncmp(ar->ar_path, chrootpath, chrootpathlen) =3D=3D 0);
+ KASSERT(ar->ar_path[chrootpathlen] =3D=3D '/' ||
+ ar->ar_path[chrootpathlen] =3D=3D '\0');
+ if (ar->ar_path[chrootpathlen] =3D=3D '\0')
+ path =3D "/";
+ else
+ path =3D ar->ar_path + chrootpathlen;
+ KASSERT(path[0] =3D=3D '/');
+ } else {
+ path =3D ar->ar_path;
+ }
+
adr->adr_id =3D ar->ar_id;
strlcpy(adr->adr_from, ar->ar_from, sizeof(adr->adr_from));
- strlcpy(adr->adr_path, ar->ar_path, sizeof(adr->adr_path));
+ strlcpy(adr->adr_path, path, sizeof(adr->adr_path));
strlcpy(adr->adr_prefix, ar->ar_prefix, sizeof(adr->adr_prefix));
strlcpy(adr->adr_key, ar->ar_key, sizeof(adr->adr_key));
strlcpy(adr->adr_options, ar->ar_options, sizeof(adr->adr_options));
@@ -489,7 +550,11 @@ autofs_ioctl_request(struct autofs_daemo
autofs_softc->sc_dev_sid =3D curproc->p_pgrp->pg_id;
mutex_exit(&proc_lock);
=20
- return 0;
+ error =3D 0;
+
+out: if (chrootpathbuf)
+ PNBUF_PUT(chrootpathbuf);
+ return error;
}
=20
static int
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP--
From: "Simon J. Gerraty" <sjg@crufty.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org, sjg@crufty.net
Subject: Re: bin/60493: autofs does not handle chroot
Date: Fri, 24 Jul 2026 19:58:20 -0700
>Would you like to try the attached patch?
>
>(Warning: totally untested; I have only verified it builds.)
Question is where should this go?
I put it on the initial ufs disk we boot from - no effect,
but perhaps it gets loaded later and thus should be on zfs /stand?
From: "Simon J. Gerraty" <sjg@crufty.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, sjg@crufty.net
Subject: Re: bin/60493: autofs does not handle chroot
Date: Fri, 24 Jul 2026 20:17:05 -0700
> I put it on the initial ufs disk we boot from - no effect,
> but perhaps it gets loaded later and thus should be on zfs /stand?
Ok, so I modunload'd autofs and loaded the new one,
when I started automountd the system panic'd
WARNING: autofs_trigger_one: cv_wait_sig for /altroot/homes/ failed with e=
rror -3
uvm_fault(0xffffffff81913520, 0xfffffffffffff000, 2) -> e
fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0xffffffff80d7bfdb cs 0x8 rflags 0x10202 cr2 0xff=
fffffffffffff9 ilevel 0 rsp 0xffffa5814efa8b50
curlwp 0xffff955182d86000 pid 2607.2607 lowest kstack 0xffffa5814efa42c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x171
panic() at netbsd:panic+0x3c
trap() at netbsd:trap+0xb32
--- trap (number 6) ---
cache_revlookup() at netbsd:cache_revlookup+0x286
getcwd_common() at netbsd:getcwd_common+0xe4
autofs_ioctl() at autofs:autofs_ioctl+0xe9
cdev_ioctl() at netbsd:cdev_ioctl+0x9b
spec_ioctl() at netbsd:spec_ioctl+0x59
VOP_IOCTL() at netbsd:VOP_IOCTL+0x47
vn_ioctl() at netbsd:vn_ioctl+0xaa
sys_ioctl() at netbsd:sys_ioctl+0x4ca
syscall() at netbsd:syscall+0x9a
--- syscall (number 54) ---
netbsd:syscall+0x9a:
cpu0: End traceback...
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Simon Gerraty <sjg@crufty.net>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/60493: autofs does not handle chroot
Date: Thu, 6 Aug 2026 19:52:39 +0000
This is a multi-part message in MIME format.
--=_nsoQjY3CD7bBvFEdm/FiyAa+axP8majm
Updated patch -- this one initializes chrootpath as the somewhat
sharp-edged getcwd_common expects, so it doesn't lead to immediate
null pointer dereference.
--=_nsoQjY3CD7bBvFEdm/FiyAa+axP8majm
Content-Type: text/plain; charset="ISO-8859-1"; name="pr60493-autofschroot-v2"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr60493-autofschroot-v2.patch"
# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1784864508 0
# Fri Jul 24 03:41:48 2026 +0000
# Branch trunk
# Node ID 6a1f5812e6f2eea24edafcaceba580dea93e45e2
# Parent b125bad3265e13dfd5a772b3676744fca85ce488
# EXP-Topic riastradh-pr60493-autofschroot
WIP: autofs: Support running inside a chroot.
PR kern/60493: autofs does not handle chroot
diff -r b125bad3265e -r 6a1f5812e6f2 sys/fs/autofs/autofs.c
--- a/sys/fs/autofs/autofs.c Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/fs/autofs/autofs.c Fri Jul 24 03:41:48 2026 +0000
@@ -75,6 +75,7 @@
#include "ioconf.h"
=20
#include <sys/atomic.h>
+#include <sys/filedesc.h>
#include <sys/queue.h>
#include <sys/signalvar.h>
=20
@@ -451,16 +452,70 @@ autofs_trigger(struct autofs_node *anp,=20
static int
autofs_ioctl_request(struct autofs_daemon_request *adr)
{
+ struct lwp *l =3D curlwp;
+ struct proc *p =3D curproc;
+ struct cwdinfo *cwdi =3D p->p_cwdi;
struct autofs_request *ar;
+ char *chrootpathbuf =3D NULL, *chrootpath =3D NULL;
+ size_t chrootpathlen =3D 0;
+ const char *path;
+ int error;
=20
+ /*
+ * If we're chrooted, find the prefix to match in requests and
+ * strip off.
+ *
+ * If we're not chrooted, don't bother with any of it: no need
+ * to allocate a pathbuf and compute getcwd(). If another
+ * thread chroots while we're working, tough.
+ */
+ if (atomic_load_relaxed(&cwdi->cwdi_rdir) !=3D NULL) {
+ /*
+ * getcwd_common builds a path backwards from the end
+ * in a given buffer. So allocate a buffer,
+ * NUL-terminate it at the end, and start with a
+ * pointer to the NUL byte. Even though PNBUF_GET
+ * allocates a buffer of MAXPATHLEN bytes (including
+ * NUL), we clamp the length of the chroot prefix
+ * somewhat arbitrarily to MAXPATHLEN/2 just like
+ * statvfs(2) and getvfsstat(2).
+ */
+ chrootpathbuf =3D PNBUF_GET();
+ chrootpath =3D chrootpathbuf + MAXPATHLEN;
+ *--chrootpath =3D '\0';
+
+ rw_enter(&cwdi->cwdi_lock, RW_READER);
+ error =3D getcwd_common(cwdi->cwdi_rdir, rootvnode, &chrootpath,
+ chrootpathbuf, MAXPATHLEN/2, 0, l);
+ rw_exit(&cwdi->cwdi_lock);
+ if (error)
+ goto out;
+ chrootpathlen =3D strlen(chrootpath);
+ }
+
+ /*
+ * Wait until there is a request that is:
+ *
+ * (a) not done,
+ * (b) not in progress by another thread,
+ * (c) if we're chrooted, within our chroot.
+ *
+ * Once we have one, mark it in progress so other threads don't
+ * take it.
+ */
mutex_enter(&autofs_softc->sc_lock);
for (;;) {
- int error;
TAILQ_FOREACH(ar, &autofs_softc->sc_requests, ar_next) {
if (ar->ar_done)
continue;
if (ar->ar_in_progress)
continue;
+ if (chrootpathlen > 1 &&
+ (strncmp(ar->ar_path, chrootpath, chrootpathlen)
+ !=3D 0 ||
+ (ar->ar_path[chrootpathlen] !=3D '/' &&
+ ar->ar_path[chrootpathlen] !=3D '\0')))
+ continue;
break;
}
=20
@@ -471,16 +526,34 @@ autofs_ioctl_request(struct autofs_daemo
&autofs_softc->sc_lock);
if (error) {
mutex_exit(&autofs_softc->sc_lock);
- return error;
+ goto out;
}
}
=20
ar->ar_in_progress =3D true;
mutex_exit(&autofs_softc->sc_lock);
=20
+ /*
+ * If we're chrooted, strip the chroot prefix off ar->ar_path.
+ * Otherwise, just use ar->ar_path as is for the adr->adr_path
+ * we return to userland.
+ */
+ if (chrootpathlen > 1) {
+ KASSERT(strncmp(ar->ar_path, chrootpath, chrootpathlen) =3D=3D 0);
+ KASSERT(ar->ar_path[chrootpathlen] =3D=3D '/' ||
+ ar->ar_path[chrootpathlen] =3D=3D '\0');
+ if (ar->ar_path[chrootpathlen] =3D=3D '\0')
+ path =3D "/";
+ else
+ path =3D ar->ar_path + chrootpathlen;
+ KASSERT(path[0] =3D=3D '/');
+ } else {
+ path =3D ar->ar_path;
+ }
+
adr->adr_id =3D ar->ar_id;
strlcpy(adr->adr_from, ar->ar_from, sizeof(adr->adr_from));
- strlcpy(adr->adr_path, ar->ar_path, sizeof(adr->adr_path));
+ strlcpy(adr->adr_path, path, sizeof(adr->adr_path));
strlcpy(adr->adr_prefix, ar->ar_prefix, sizeof(adr->adr_prefix));
strlcpy(adr->adr_key, ar->ar_key, sizeof(adr->adr_key));
strlcpy(adr->adr_options, ar->ar_options, sizeof(adr->adr_options));
@@ -489,7 +562,11 @@ autofs_ioctl_request(struct autofs_daemo
autofs_softc->sc_dev_sid =3D curproc->p_pgrp->pg_id;
mutex_exit(&proc_lock);
=20
- return 0;
+ error =3D 0;
+
+out: if (chrootpathbuf)
+ PNBUF_PUT(chrootpathbuf);
+ return error;
}
=20
static int
--=_nsoQjY3CD7bBvFEdm/FiyAa+axP8majm--
From: "Simon J. Gerraty" <sjg@crufty.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org, sjg@crufty.net
Subject: Re: bin/60493: autofs does not handle chroot
Date: Fri, 07 Aug 2026 17:29:04 -0700
>Updated patch -- this one initializes chrootpath as the somewhat
>sharp-edged getcwd_common expects, so it doesn't lead to immediate
>null pointer dereference.
Thanks, I'll have to think about how to test this, since no
longer running zfs with the ramdisk trick.
From: "Simon J. Gerraty" <sjg@crufty.net>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, sjg@crufty.net
Subject: Re: bin/60493: autofs does not handle chroot
Date: Fri, 07 Aug 2026 18:19:43 -0700
On Sat, 8 Aug 2026 00:30:01 +0000 (UTC), "Simon J. Gerraty via gnats" writ=
es:
> >Updated patch -- this one initializes chrootpath as the somewhat
> >sharp-edged getcwd_common expects, so it doesn't lead to immediate
> >null pointer dereference.
> =
> Thanks, I'll have to think about how to test this, since no
> longer running zfs with the ramdisk trick.
Ok not sure how valid this is...
I stopped auto*mount*
I built and loaded the new autofs module.
restarted auto*mount* and confirmed autofs still worked.
I stopped auto*mount*
and created a quick and dirty chroot
/h/tmp/chroot/ with a full copy of /etc
and just enough of /lib and /libexec to run =
cat /h/tmp/chroot/tmp/tit.sh
#/bin/sh
/etc/rc.d/autounmountd start
/etc/rc.d/automountd start
/etc/rc.d/automount start
df -h /homes/sjg/tmp
when I ran that it hung at df
dmesg says
[ 511376.695498] WARNING: autofs_trigger_one: cv_wait_sig for /h/tmp/chroo=
t/homes/ failed with error -3
From: "Simon J. Gerraty" <sjg@crufty.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org, sjg@crufty.net
Subject: Re: bin/60493: autofs does not handle chroot
Date: Wed, 19 Aug 2026 16:05:00 -0700
TL;DR; the latest patch in the PR worked.
>The kernel will print the full path (ar_path in autofs_trigger_one).
>What's interesting is what path it passed to automountd (adr_path in
>autofs_ioctl_request) and whether automountd did anything.
>
>Sounds like it's time for some printf debugging!
>
>You could also just try ktracing automountd to see if the ioctl
>response looks sensible.
Ok, I unpacked base and etc sets in chroot and
created auto_master that only defines one map /pics (~/bin/autofs just
runs all the rc.d/auto* in correct order)
# ~/bin/autofs off
# chroot $ROOT /bin/ksh
# ~/bin/autofs on
# ls /pics/2026
that at least did not hang.
# mount
map /etc/autofs/pics on /pics type autofs
/dev/dk6 on / type ffs (local)
#
I note that auto* created /pics ok
# ktrace -i -f /var/tmp/kt -p `cat /var/run/automountd.pid`
# ls /pics/2026
# ls /pics/2025
# ktrace -C
# kdump -E -f /var/tmp/kt > /var/tmp/kd
/var/tmp/kd shows
..
17093 17093 mount_nfs 0.002363788 CALL __lstat50(0x7f7fffe02470,0x7f7ff=
=3D
fe01620)
17093 17093 mount_nfs 0.002365394 NAMI "/pics"
17093 17093 mount_nfs 0.002369445 RET __lstat50 0
17093 17093 mount_nfs 0.002370911 CALL __lstat50(0x7f7fffe02470,0x7f7ff=
=3D
fe01620)
17093 17093 mount_nfs 0.002372098 NAMI "/pics/2026"
that's promising
..
17093 17093 mount_nfs 0.031513795 CALL connect(5,0x7734ec9d2080,0x10)
17093 17093 mount_nfs 0.031514633 MISC mbsoname: [192.168.66.6]
17093 17093 mount_nfs 0.032295206 RET connect 0
that's the server
..
17093 17093 mount_nfs 0.032299746 CALL getsockname(5,0x7f7fffe01ab0,0x7=
=3D
f7fffe
01aa8)
17093 17093 mount_nfs 0.032301073 MISC mbsoname: [192.168.66.11]
17093 17093 mount_nfs 0.032302050 RET getsockname 0
that's the client
..
17093 17093 mount_nfs 0.032401359 CALL write(5,0x7734ec904b80,0x80)
17093 17093 mount_nfs 0.032409041 GIO fd 5 wrote 128 bytes
"\M^@\0\0|\M-R\^[@N\0\0\0\0\0\0\0\^B\0\^A\M^F\M-%\0\0\0\^C\0\0\0\^A=
=3D
\0\0\
\0\^A\0\0\0Djz\^T\M-`\0\0\0\^Nbad.crufty.net\0\0\0\0\0\0\0\0\0\0\0=
=3D
\0\0\
\b\0\0\0\0\0\0\0\^B\0\0\0\^C\0\0\0\^D\0\0\0\^E\0\0\0\^T\0\0\0\^_\0=
=3D
\0\0\
\"\0\0\0\0\0\0\0\0\0\0\0\n/pics/2026\0\0"
17093 17093 mount_nfs 0.032410019 RET write 128/0x80
that looks like a sane request?
..
17093 17093 mount_nfs 0.033066840 CALL read(5,0x7734ec8f3c00,0x10000)
17093 17093 mount_nfs 0.033083322 GIO fd 5 read 32 bytes
"\M^@\0\0\^\\M-R\^[@N\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
=3D
\0\r"
17093 17093 mount_nfs 0.033084160 RET read 32/0x20
I presume that's the response
..
17093 17093 mount_nfs 0.033127529 CALL write(2,0x7f7fffe01780,0xb)
17093 17093 mount_nfs 0.033131929 GIO fd 2 wrote 11 bytes
"mount_nfs: "
17093 17093 mount_nfs 0.033132906 RET write 11/0xb
17093 17093 mount_nfs 0.033134932 CALL write(2,0x7f7fffe01860,0x2a)
17093 17093 mount_nfs 0.033136468 GIO fd 2 wrote 42 bytes
"can't access /pics/2026: Permission denied"
..
17093 17093 mount_nfs 0.033198553 CALL exit(1)
17702 17702 automountd 0.033440959 RET __wait450 -1 errno 4 Interrupte=
=3D
d system call
17702 17702 automountd 0.033444451 PSIG SIGCHLD caught handler=3D3D0xab=
f7=3D
0 mask=3D3D(): code=3D3DCLD_EXITED child pid=3D3D17093, uid=3D3D0, status=3D=
3D1, uti=3D
me=3D3D0, stime=3D3D0)
Everything about that seemed sane - apart from the result ;-)
Check the server and we see
Aug 10 11:26:02 beast mountd[74725]: mount request denied from 192.168.66.=
11 for /pics/2026
Ok, export of /pics is missing --alldirs (as we have on /homes)
Mounting just /pics works fine within chroot:
# ~/bin/autofs off
mount beast:/pics /pics
# ls /pics/2026
01 03 07 index.htm meta.prope=
=3D
rties
02 05 08 index.htm.old
# umount /pics
Add -alldirs and try again
# ~/bin/autofs on
# ls /pics/2026
01 03 07 index.htm meta.prope=
=3D
rties
02 05 08 index.htm.old
#
success!
Thanks
--sjg
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60493 CVS commit: src/sys/fs/autofs
Date: Thu, 20 Aug 2026 20:24:23 +0000
Module Name: src
Committed By: riastradh
Date: Thu Aug 20 20:24:23 UTC 2026
Modified Files:
src/sys/fs/autofs: autofs.c
Log Message:
autofs: Support running inside a chroot.
PR kern/60493: autofs does not handle chroot
To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sys/fs/autofs/autofs.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 20 Aug 2026 20:26:09 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10, pullup-9
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home