The reason I went with an explicit "-R" is that I thought having mountd
magically stop registering with rpcbind might be considered a POLA
violation.
--> With the explicit "-R" option, it will only happen if the "-R" flag is
set or if nfsv4_server_only="YE
Suggestion:
Add a check for sysctl vfs.nfsd.server_min_nfsvers and if set to 4 or higher -
automatically enable the “-R” option.
- Peter
> On 20 Oct 2020, at 02:56, Rick Macklem wrote:
>
> Hi,
>
> I've put a patch up on phabricator that adds a new option to mountd
>
Hi,
I've put a patch up on phabricator that adds a new option to mountd
which disables use of rpcbind. This can be done for NFSv4 only servers.
It appears that rpcbind is now considered a security risk by some.
I listed freqlabs@ as a reviewer, but if anyone else would like to review
it, p
On May 19, 2019 12:00:58 PM EDT, Rick Macklem wrote:
>
>
>Cy Schubert wrote:
>[lots of stuff snipped]
>>Instead of syslog() calls, DTrace probes are designed for this type of
>instrumentation.
>
>DTrace us way too obscure for me. Never used it, probably neve
Cy Schubert wrote:
[lots of stuff snipped]
>Instead of syslog() calls, DTrace probes are designed for this type of
>instrumentation.
DTrace us way too obscure for me. Never used it, probably never will.
(Remember I'm the guy who still uses "ed" to edit a
On May 19, 2019 4:55:01 AM EDT, Konstantin Belousov wrote:
>On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote:
>> Alan Somers wrote:
>> >On Sat, May 18, 2019 at 7:59 PM Rick Macklem
>wrote:
>> >>
>> >> Hi,
>> >>
>> >
On Sun, May 19, 2019 at 02:47:10AM +, Rick Macklem wrote:
> Alan Somers wrote:
> >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote:
> >>
> >> Hi,
> >>
> >> I've been working with Peter Errikson on a patch for mountd that adds a
> >>
Alan Somers wrote:
>On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote:
>>
>> Hi,
>>
>> I've been working with Peter Errikson on a patch for mountd that adds a new
>> option
>> for incremental updating of exports. This seems to be helping a lot w.r
On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote:
>
> Hi,
>
> I've been working with Peter Errikson on a patch for mountd that adds a new
> option
> for incremental updating of exports. This seems to be helping a lot w.r.t.
> performance
> on an NFS server with l
Hi,
I've been working with Peter Errikson on a patch for mountd that adds a new
option
for incremental updating of exports. This seems to be helping a lot w.r.t.
performance
on an NFS server with lots (1+) of exported file systems.
I have debug syslog() calls in the code, which I/
On Sun, May 14, 2017 at 01:12:11AM +, Rick Macklem wrote:
> >> It is also the case that mountd.c doesn't look "nobody" up in the password
> >> database
> >> to set the default. It would be nice to do this, but it could result in
> >> t
Thanks for the comments.
>> It is also the case that mountd.c doesn't look "nobody" up in the password
>> database
>> to set the default. It would be nice to do this, but it could result in the
>> mountd daemon
>> getting "stuck" during a
t; up in the password
> database
> to set the default. It would be nice to do this, but it could result in the
> mountd daemon
> getting "stuck" during a boot waiting for an unresponsive LDAP service or
> similar.
> Does doing this sound like a good idea?
I imagine t
assword
> database
> to set the default. It would be nice to do this, but it could result in the
> mountd daemon
> getting "stuck" during a boot waiting for an unresponsive LDAP service or
> similar.
> Does doing this sound like a good idea?
This is (stuck at boot) alrea
ountd.c doesn't look "nobody" up in the password
database
to set the default. It would be nice to do this, but it could result in the
mountd daemon
getting "stuck" during a boot waiting for an unresponsive LDAP service or
similar.
Does doing this sound like a good idea?
exported via ZFS properties.
So, it has /etc/zfs/exports, but no /etc/exports.
When mountd is started up, it emits a error, because the
required_files is set to /etc/exports.
I think the correct thing is to either remove the required_files
setting, or build it from /etc/exports and/or /etc/zfs
> > Thanks for the suggestion Doug, rick
> > >
> > > > On 7 May 2015 at 02:10, Rick Macklem
> > > > wrote:
> > > >
> > > > > David Boyd reported a problem to freebsd-current@ w.r.t. the
> > > > > MNT_AUTOMOUNTED
s. (Feel free to add yourself as a
> > reviewer, etc.)
> >
> > Also, David, if you can test this patch, it would be appreciated.
> >
> > Thanks for the suggestion Doug, rick
> >
> > > On 7 May 2015 at 02:10, Rick Macklem wrote:
> > >
&
d.
>
> Thanks for the suggestion Doug, rick
>
> > On 7 May 2015 at 02:10, Rick Macklem wrote:
> >
> > > David Boyd reported a problem to freebsd-current@ w.r.t. the
> > > MNT_AUTOMOUNTED
> > > flag getting cleared by mountd.
> > > h
.r.t. the
> > MNT_AUTOMOUNTED
> > flag getting cleared by mountd.
> > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
> > I just took a look at this and it's kinda ugly...
> >
> > mountd acquires a list of mounts via getmntinfo() and then do
2015 at 02:10, Rick Macklem wrote:
>
> > David Boyd reported a problem to freebsd-current@ w.r.t. the
> > MNT_AUTOMOUNTED
> > flag getting cleared by mountd.
> > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
> > I just took a look at this and
You could add a single integer-valued vfsopt which holds the high-order
bits of f_flags?
On 7 May 2015 at 02:10, Rick Macklem wrote:
> David Boyd reported a problem to freebsd-current@ w.r.t. the
> MNT_AUTOMOUNTED
> flag getting cleared by mountd.
> http://docs.FreeBSD.org
David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED
flag getting cleared by mountd.
http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
I just took a look at this and it's kinda ugly...
mountd acquires a list of mounts via getmntinfo() and then does an
n
On Sat, Jun 30, 2012 at 08:53:09PM -0400, Rick Macklem wrote:
> I haven't looked at Andrey's patch, but conceptually it sounds like
> the best approach. As I understand it, the problem with replacing
> mountd with nfse (at least in the FreeBSD source tree) is that nfse
>
On 06/24/2012 16:07, Steven Hartland wrote:
> We added some new mount points recently and on reboot they failed to
> come up after investigating we found that mountd runs too early in
> the boot process to be able export filesystems that are marked as
> late in /etc/fstab.
>
>
We added some new mount points recently and on reboot they failed to
come up after investigating we found that mountd runs too early in
the boot process to be able export filesystems that are marked as
late in /etc/fstab.
Our fix was simply to mark mountd as requiring mountlate and all
was well
On Thu, Apr 19, 2012 at 08:44:37PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:
> > On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
> > > Hi,
> > >
> > > I have patches for the mountd, rpc.statd and rpc.lockd daemons
> > > th
work to
obtain a port number before using it in tcpdump or in firewall settings.
I checked rpcinfo output for mountd on Solaris and NetBSD, on both
systems mountd can use different ports for different netconfigs.
> > 2. What is the sense of specifying specific IP addresses for mountd
> >
Andrey Simonenko wrote:
> On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > I have patches for the mountd, rpc.statd and rpc.lockd daemons
> > that are meant to keep them from failing when a dynamically
> > selected port# is not
On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
> Hi,
>
> I have patches for the mountd, rpc.statd and rpc.lockd daemons
> that are meant to keep them from failing when a dynamically
> selected port# is not available for some combination of
> udp,tcp X ipv4,i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 08/29/11 11:47, Rick Macklem wrote:
>> I think it did. Lookup of ".." was failing. I think that was because
>> ni_strictrelative (added for capabilities) wasn't initialized and
>> happened to be non-zero.
>
>> Please try this patch and let us
Steve Wills wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/27/11 21:23, Steve Wills wrote:
> > On 08/27/11 20:55, Rick Macklem wrote:
> >>> I don't know why the nfsd wouldn't be able to bind(2) to port
> >>> #2049 a
> >>> second time for UDP, but someone on the net side might k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/27/11 21:23, Steve Wills wrote:
> On 08/27/11 20:55, Rick Macklem wrote:
>>> I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a
>>> second time for UDP, but someone on the net side might know? (Just in
>>> case it is a problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/27/11 20:55, Rick Macklem wrote:
>> I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a
>> second time for UDP, but someone on the net side might know? (Just in
>> case it is a problem that has already been fixed, I'd try a newe
0 2 udp 0.0.0.0.0.111 rpcbind superuser
> > 10 4 tcp6 ::.0.111 rpcbind superuser
> > 10 3 tcp6 ::.0.111 rpcbind superuser
> > 10 4 udp6 ::.0.111 rpcbind superuser
> > 10 3 udp6 ::.0.111 rpcbind superuser
> > 10 4 local /var
Steve Wills wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/27/11 09:00, Rick Macklem wrote:
> >> This line indicates that mountd over tcp is registered for v3,
> >> so I suspect the error message is misleading??
>
> Forgot to reply to th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/27/11 09:00, Rick Macklem wrote:
>> This line indicates that mountd over tcp is registered for v3,
>> so I suspect the error message is misleading??
Forgot to reply to this part, and I should have been more clear earlier.
Whe
0 2 udp 0.0.0.0.0.111 rpcbind superuser
> > 10 4 tcp6 ::.0.111 rpcbind superuser
> > 10 3 tcp6 ::.0.111 rpcbind superuser
> > 10 4 udp6 ::.0.111 rpcbind superuser
> > 10 3 udp6 ::.0.111 rpcbind superuser
> > 10 4 local /var
4local /var/run/rpcbind.sock rpcbindsuperuser
> 103local /var/run/rpcbind.sock rpcbindsuperuser
> 10 2local /var/run/rpcbind.sock rpcbindsuperuser
> 151udp6 ::.2.224 mountd
superuser
103udp6 ::.0.111 rpcbindsuperuser
104local /var/run/rpcbind.sock rpcbindsuperuser
103local /var/run/rpcbind.sock rpcbindsuperuser
102local /var/run/rpcbind.sock rpcbindsuperuser
10
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0.
When I attempt the mount, it logs this message:
The NFS server does not support MOUNT version 3 over TCP
Have I configured something wrong and if so what? Or is this somethi
Hi,
I have patches for the mountd, rpc.statd and rpc.lockd daemons
that are meant to keep them from failing when a dynamically
selected port# is not available for some combination of
udp,tcp X ipv4,ipv6
If anyone would like to test these patches, they can be found
at:
http
gt; does not include ext2fs or hpfs, so you can successfully export
>> these filesystems, but they remain exported even when the /etc/exports
>> entry is removed and mountd is restarted or sent a SIGHUP, and no
>> errors are logged...
>
>This is actually the wrong way to go
ilesystem across the network.
As a security thing, it cuts both ways; it really depends on your
policy basis.
In general, this is handled by adding an option to the mountd to
only export whole FSs, to get around the cut the other direction
(I think this is "-subdirs" on SunOS, but it has b
On Fri, Dec 14, 2001 at 10:17:43PM -0800, Terry Lambert wrote:
> The problem is that the exported FSs exports are managed in the
> per FS mount code, and they really ought to be managed in higher
> level code (above the VFS layer, but still in the kernel).
>
> This is incidently what prevents us
Ian Dowse wrote:
>
> There are quite a few assumptions in mountd(8) about the layout of
> the per-filesystem mount(2) `data' struct, which make the code quite
> ugly. It uses a union to ensure that it supplies a large enough
> structure to mount(2), but regardless of the
There are quite a few assumptions in mountd(8) about the layout of
the per-filesystem mount(2) `data' struct, which make the code quite
ugly. It uses a union to ensure that it supplies a large enough
structure to mount(2), but regardless of the filesystem type, it
always initialises th
I braino'd that patch (error vs. errno), but I have just committed
> a working version that should stop the mountd warnings.
>
> Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Thanks, Ian!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>error? (untested patch below).
I braino'd that patch (error vs. errno), but I have just committed
a working version that should stop the mountd warnings.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
Le 2001-05-28, Matthew Jacob écrivait :
> On startup:
> May 28 10:16:04 farrago mountd[216]: can't delete exports for /
Same here with -CURRENT as of today.
--
Thomas Quinot ** Département Informatique & Réseaux ** [EMAIL PROTECTED]
ENST // 46 rue Barrault /
In message <[EMAIL PROTECTED]>, John writes:
>Looking in /usr/src/sbin/mountd/mountd.c, under line 930
>shows the following:
>
>num = getmntinfo(&fsp, MNT_NOWAIT);
>
>and then runs through a loop 'num' times trying to
>delete any export for eac
- Ian Dowse's Original Message -
> In message <[EMAIL PROTECTED]>, John Polstra writes:
> >In article <[EMAIL PROTECTED]>,
> >Matthew Jacob <[EMAIL PROTECTED]> wrote:
> >> May 28 10:21:43 farrago mountd[217]: can't delete exports for
In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>Matthew Jacob <[EMAIL PROTECTED]> wrote:
>> May 28 10:21:43 farrago mountd[217]: can't delete exports for /tmp
>> May 28 10:21:43 farrago mountd[217]: can't delete
In article <[EMAIL PROTECTED]>,
Matthew Jacob <[EMAIL PROTECTED]> wrote:
>
> Over the last couple of weeks, I've seen wierd statements coming out of
> mountd:
>
> On startup:
>
> May 28 10:16:04 farrago mountd[216]: can't delete exports for /
>
Over the last couple of weeks, I've seen wierd statements coming out of
mountd:
On startup:
May 28 10:16:04 farrago mountd[216]: can't delete exports for /
On a mount of /usr/obj:
May 28 10:21:43 farrago mountd[217]: can't delete exports for /tmp
May 28 10:21:43 farrago mou
/etc/hosts.{allow,deny}.
But my hosts.allow is up to date as of May 5th ...
May 12 01:10:40 thelab nfsd:[6310]: rpcb_unset failed
May 12 01:17:33 thelab nfsd:[20226]: rpcb_unset failed
May 12 01:17:48 thelab mountd[21102]: can't delete exports for /
May 12 01:17:48 thelab mountd[21102]: can
* John Baldwin <[EMAIL PROTECTED]> [010123 12:41] wrote:
>
> On 23-Jan-01 Julian Elischer wrote:
> > Suddenly the following error messages occur:
> > Jan 23 07:21:02 jules mountd[435]: can't export /unused
> > Jan 23 07:21:02 jules mountd[435]: bad exports list
On 23-Jan-01 Julian Elischer wrote:
> Suddenly the following error messages occur:
> Jan 23 07:21:02 jules mountd[435]: can't export /unused
> Jan 23 07:21:02 jules mountd[435]: bad exports list line /unused
> -maproot
> Jan 23 07:21:02 jules mountd[435]: could not remount
Suddenly the following error messages occur:
Jan 23 07:21:02 jules mountd[435]: can't export /unused
Jan 23 07:21:02 jules mountd[435]: bad exports list line /unused -maproot
Jan 23 07:21:02 jules mountd[435]: could not remount /usr: Bad address
Jan 23 07:21:02 jules mountd[435]: bad ex
On Thu, 21 Jan 1999, David E. Cross wrote:
> I posted this awhile ago to -questions, but never received a reply.
>
> We have a number of FreeBSD NFS servers here. Occasionally we need to
> change the exports list on the servers and send mountd a SIGHUP. This
> leads to a conditi
On Thu, 21-Jan-1999 at 10:54:36 -0500, David E. Cross wrote:
> I posted this awhile ago to -questions, but never received a reply.
>
> We have a number of FreeBSD NFS servers here. Occasionally we need to
> change the exports list on the servers and send mountd a SIGHUP. This
I posted this awhile ago to -questions, but never received a reply.
We have a number of FreeBSD NFS servers here. Occasionally we need to
change the exports list on the servers and send mountd a SIGHUP. This
leads to a condition that in many ways is much worse than a server reboot.
What
63 matches
Mail list logo
