[Bug 193953] vlan(4) on LACP lagg(4) do not update if_baudrate value and thus SNMP daemons do not provide high capacity counters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193953 --- Comment #16 from Marek Zarychta --- Thank you for the MFC[1] to stable/13 Wojciech. I am not the reporter, but it's probably time to close this almost 8 years old bug. [1] https://cgit.freebsd.org/src/commit/?id=067a4b656b9b -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Re: NFSv4 on MacOS Monterey
Adonis Peralta wrote: > Rick Macklem wrote: > > Yep, as noted above, they aren't supported and will not work. FreeBSD uses > > the Linux style extended > > attribute model, not the resource fork/subfile one that Mac OSX and Solaris > > use. > > > > Is this still the case if the shares are on ZFS? Yes. > Is there any info on when or if FreeBSD will get namedattr support? It has been discussed and I have seen no indication that namedattr/ resource forks will ever be implemented. The same appears to be true of Linux. I recall that there were significant issues related to userspace things like archivers, etc. There would also be significant changes needed to the VOP/VFS, since resource forks (or whatever you call them) are really files in a different namespace. rick -- Adonis
Re: NFSv4 on MacOS Monterey
>> mountd_enable="YES" > Since you have specified nfsv4_server_only, mountd will be configured > correctly (using the -R), > so this line is not needed (although I don't thing it will cause trouble). Got it. >> My configuration is as follows: >> >> SERVER CONFIGURATION >> >> OS: FreeBSD 13.1 >> >> === >> /etc/rc.conf >> # NFS Configuration >> nfs_server_enable="YES" >> nfs_server_flags="-u -t -n 4" > 4 is very small, although that will only be a performance issue. Increased to 12. >> === >> /etc/sysctl.conf >> # Asks nfsd to convert remote uids/gid encoded as numeric strings to be >> mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=1 > You probably do not want this. Since you are running nfsuserd, it will be > mapping between > the client uid/gid <-> the names for the Getattr/Setattr. > If the Mac OSX client does not have "adonis" in its password database, that > will be a problem. > (These mappings have nothing to do with the uid/gids in the RPC header. The > latter is used > to set the credentials for the RPC against the server. In your case, > completely ignored. > The name<->uid/gid mappings are used for Setattr/Getattr. Things like > "chmod", "stat"...) > Ok got it. So by default /etc/passwd doesn't have my user "adonis" but /etc/passwd on MacOS states: === ## # User Database # # Note that this file is consulted directly only when the system is running # in single-user mode. At other times this information is provided by # Open Directory. # # See the opendirectoryd(8) man page for additional information about # Open Directory. ## === I believe there shouldn't be a problem because as I state a little down below MacOS is sending the uid/gid as names as per below: >> /etc/sysctl.conf >> # Asks nfsd to convert remote uids/gid encoded as numeric strings to be >> mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=1 > You probably do not want this. Since you are running nfsuserd, it will be > mapping between > the client uid/gid <-> the names for the Getattr/Setattr. > If the Mac OSX client does not have "adonis" in its password database, that > will be a problem. > (These mappings have nothing to do with the uid/gids in the RPC header. The > latter is used > to set the credentials for the RPC against the server. In your case, > completely ignored. > The name<->uid/gid mappings are used for Setattr/Getattr. Things like > "chmod", "stat"...) > >> # Applies to both nfs server and client. Asks client/server to send numeric >> strings for uid/gid. >> ### vfs.nfs.enable_uidtostring=0 > For a server, you either set both of the above to 1 and do not run the > nfsuserd or set both of the > above to 0 and set them both to 0. I do not know if Mac OSX knows how to do > the "uid/gid" in > the string for Getattr/Setattr, That is what you are doing when the above are > set to 1 and is the > default for Linux, plus works for FreeBSD so long as you are not using > Kerberized mounts. > (To know, you would need to look a Setattr RPC done by the Mac OSX client in > wireshark for > either "chgrp" or "chown" and see how the Owner/Owner_Group string is > formatted. A number > or a "name@domain".) > I inspected the packet trace for what MacOS sends for setattr when doing something like "chown adonis:wheel on a file" and indeed it does send name strings for OWNER and OWNER_GROUP in the following format "ado...@rambo.lan for OWNER" and "wh...@rambo.lan for OWNER_GROUP". Given that, I set vfs.nfsd.enable_stringtouid back to 0. >> 2. Extended attributes don't work at all. Here is the result: >> === >> $ cd /Volumes/media >> $ touch test.txt >> $ xattr -w com.example.color blue test.txt >> >> # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # >> === > Yep, as noted above, they aren't supported and will not work. FreeBSD uses > the Linux style extended > attribute model, not the resource fork/subfile one that Mac OSX and Solaris > use. > Is this still the case if the shares are on ZFS? Is there any info on when or if FreeBSD will get namedattr support? -- Adonis
Re: NFSv4 on MacOS Monterey
Rick Macklem wrote: > Adonis Peralta wrote: [stuff snipped] > > OS: FreeBSD 13.1 [more stuff snipped] > > RESULTS > > > > What I see when I connect via finder is the following: > > > > 1. I am able to read/write to the shares since /etc/exports contains the > > -mapall line, yet inspecting a packet > trace shows me: > > > > === > > packet #1 > > --- > > client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR > > Opcode: PUTFH (22) > > Opcode: ACCESS (3), [Check: RD LU MD XT DL XE] > > Opcode: GETATTR (9) > > > > packet #2 > > --- > > server ip -> client ip Operations (count: 3) > > Opcode: PUTFH (22) > > Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], > > [Allowed: RD LU] > > Status: NFS4_OK (0) > > Supported types (of requested): 0x1f > >Access rights (of requested): 0x03 > > ...1 = 0x001 READ: allowed > > ..1. = 0x002 LOOKUP: allowed > > .0.. = 0x004 MODIFY: *Access Denied* > > 0... = 0x008 EXTEND: *Access Denied* > >...0 = 0x010 DELETE: *Access Denied* > This is saying that the uid for "adonis" on the server does not have write > access to the file. > > > Opcode: GETATTR (9) > > === > > > > Why is MD, XT, DL coming up as Access Denied if I can read/write to the > > > share? > Hmm, not sure. If you were to show all the reply fields for the Getattr, then > > I could probably guess. > It might be Owner (is it "ado...@rambo.lan"). it could be ACLs. To check > those, you should be able to > do whatever the Mac OSX equivalent to getfacl is. I suspect this might be caused by what is called OwnerOverride. It is a long standing tradition in NFS servers to allow the owner of a file to read/write the file despite what the file mode/ACL says. Why? Well, because unlike POSIX, NFS servers check permissions on every Read/Write instead of only upon the POSIX open(2). Without this, POSIX applications that first open(2) a file and then chmod(2) the file to a mode that does not allow further open(2)s of the same type, will break badly on NFS mounts. (NFS is not and will never be a POSIX compliant file system, due to the protocol.) This "cheat" of allowing the Owner access regardless, allows most of these POSIX programs to work over NFS. (And since the owner of the file can chmod/Setattr of mode at any time, it is not considered a security hole.) Now, for NFSv4, there is an Open (a form of Windows lock, not a POSIX open). It should fail for the case where it is not doing a Create and the permissions are not allowed. (This check was only added to the FreeBSD server recently, when it was identified as not doing the check, unlike Linux and Solaris. However, this check is in 13.1.) I can only conjecture that the NFSv4 Open specified Create in this case and, as such, the check was not applied. NFSv4 clients are expected to use the reply to Access to decide whether or not to permit the POSIX open(2). It appears that the Mac OSX client may not be doing this? rick > I have a feeling this is because UID/GID mapping is not happening correctly. > I can see in the packet trace >that FreeBSD's `nfsd` is sending some > credentials as `ado...@rambo.lan`, but MacOS's nfs client is sending uid 501 > and gid 20 for my user in the RPC credentials. I don't see how `nfsd` will be > able to map uid 501, gid 20 to the server's uid and gid and instead I was > expecting `ado...@rambo.lan` to be sent for credentials from the client side. As noted above, with "-mapall" the uid/gids in the RPC header are completely ignored. > The link below tells me that this is an inherent issue with NFSv4? > https://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+with+AUTH_UNIX > > 2. Extended attributes don't work at all. Here is the result: > === > $ cd /Volumes/media > $ touch test.txt > $ xattr -w com.example.color blue test.txt > > # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # > === Yep, as noted above, they aren't supported and will not work. FreeBSD uses the Linux style extended attribute model, not the resource fork/subfile one that Mac OSX and Solaris use. rick -- Adonis
[Bug 264193] pf: scrub max-mss rule stops working (but still counts) after 13.1-RELEASE upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264193 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Kristof Provost --- Created attachment 234397 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234397=edit Teset case I can't seem to reproduce this here. The attached test cases passes on main and stable/13 for me. -- You are receiving this mail because: You are on the CC list for the bug.
Re: make NFSv3 default now on diskless
On Thu, Jun 02, 2022 at 08:03:05PM +, Rick Macklem wrote:
> John-Mark Gurney wrote:
> > Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +:
> > > John-Mark Gurney wrote:
> > > > I just booted FreeBSD-current diskless, using NFS root, and I ended
> > > > up having issues because by default, NFS root is only v2.
> > > >
> > > > One of things that happened was disk space available was listed as
> > > > -138G, or -144830429K. I assume this is because the server is reporting
> > > > TBs instead.
> > > Yes. NFSv2 uses 32bit sizes.
> >
> > Should we make the NFS server clamp various sizes then? instead of
> > reporting
> > negative numbers? (Sorry if this is already done on newer versions of
> > FreeBSD, my server is a bit old.)
> My recollection (from long ago) is that, although the RFC defined them as
> 32bit signed,
> some implementations choose to mid-interpret them as unsigned, so that 4G was
> supported
> instead of 2G.
>
> Having said that, I agree with you that you should just use NFSv3 now. (Many
> servers are
> dropping NFSv2 support entirely.)
>
> > > > If I mount via mount_nfs, the sizes are normal/correct because it mounts
> > > > v3.
> > > I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on the
> > > remote root fs. Then, when the system does a "mount -u" to make it
> > > read/write it gets toggled to NFSv3.
> >
> > well, I tried doing a:
> > mount -u -o nfsv3 /
> It used to work when it was in /etc/fstab, when going from read-only to
> read-write,
> from what I recall.
>
> > on the system and this didn't work switch over to v3, it was still on
> > v2..
> >
> > I haven't specified nfsv3 in /etc/fstab, but IMO, this should be the
> > default..
> Since NFSv3 is the default, it might not need to be explicit. I can't recall.
>
> >
> > Also, I'm right now booting single user mode, because I'm -mapall to
> > a user, and lots of FreeBSD breaks when files aren't uid 0, and there
> > doesn't appear to be a way to remap the uid to root (that I have found)..
> Yep. It would take effect when going multi-user.
>
> "-mapall=root", although that is not a recommended security setting.
> Why don't you just allow the client to use whatever uid it would normally
> use instead of "-mapall"?
>
> > > > The other issue that I ran into is that NFSv2 can't access >4GB files
> > > > (or create them).
> > > As above, NFSv2 uses 32bit sizes.
> > >
> > > > Anyone object to adding BOOTP_NFSV3 to GENERIC?
> > > Well, that option only works when used with BOOTP_NFSROOT.
> > > The GENERIC configs for amd64, arm64,... use the other way.
> > > (Just to make it confusing, there are two different ways an NFS root
> > > fs is set up.)
> > > See below.
> > >
> > > > Or maybe making it a
> > > > tunable that defaults to set, because it seems a bit crazy to default
> > > > to v2 these days.
> > > I don't think changing the default to NFSv3 will be a problem.
> > > The reason it was NFSv2 was that,
> > > for some non-FreeBSD NFS servers, the NFSv3 file handle is different
> > > than the NFSv2 one.
> > >
> > > I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every
> > > system should be running the newer NFS code in the loader and be able
> > > to do NFSv3 booting.
> > >
> > > > This option was added in 432aad0e in 1997 so that the nfs_diskless
> > > > structure didn't need to be filled out. Does anything even
> > > > populate/fill it out anymore? I saw code in i386/i386/locore.s that
> > > > does this, but it doesn't appear anywhere else.
> > > Yes. For "options NFS_ROOT" (the other way), the loader uses
> > > "stand/libsa/nfs.c" to acquire the remote file system's root file handle
> > > and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.)
> > > Looking at it, it appears to enable NFSv3 so long as it finds
> > > "boot.nfsroot.nfshandlelen" set.
> >
> > Well, I'm not seeing that, and this system is booting via
> > pxeboot+loader, so maybe something is broken?
> If it's an up to date (within last 10+ years then, yes, it sounds like it
> might be broken. However, I'm not a loader guy...
>
> You can set it manually at the loader prompt to "28" and then see if it
> boots are is running NFSv3.
>
> I have no way of testing/debugging this. Maybe you can figure out why the
> loader isn't setting "boot.nfsroot.nfshandlelen" to 28?
I have did several (> 5) lab setups with NFS booting, and it was always
like you described:
kernel config:
options NFS_ROOT
/boot/loader.conf
boot.nfsroot.options="nolockd"
nfscl_load="YES"
(yes, my nfscl.ko is a module)
/etc/fstab (an example)
192.168.130.1:/usr/home/netboot/zoo/r-freeb44 / nfs rw,nolockd
0 0
and in dhcpd.conf
host r-freeb44.zoo {
hardware ethernet 28:80:23:a2:37:bc;
fixed-address r-freeb44.zoo;
next-server rott.zoo;
filename "pxeboot";
# filename "loader.efi";
option root-path "192.168.130.1:/usr/home/netboot/zoo/r-freeb44";
}
You need pxeboot (or loader.efi)
Re: make NFSv3 default now on diskless
John-Mark Gurney wrote: > Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +: > > John-Mark Gurney wrote: > > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > > up having issues because by default, NFS root is only v2. > > > > > > One of things that happened was disk space available was listed as > > > -138G, or -144830429K. I assume this is because the server is reporting > > > TBs instead. > > Yes. NFSv2 uses 32bit sizes. > > Should we make the NFS server clamp various sizes then? instead of reporting > negative numbers? (Sorry if this is already done on newer versions of > FreeBSD, my server is a bit old.) My recollection (from long ago) is that, although the RFC defined them as 32bit signed, some implementations choose to mid-interpret them as unsigned, so that 4G was supported instead of 2G. Having said that, I agree with you that you should just use NFSv3 now. (Many servers are dropping NFSv2 support entirely.) > > > If I mount via mount_nfs, the sizes are normal/correct because it mounts > > > v3. > > I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on the > > remote root fs. Then, when the system does a "mount -u" to make it > > read/write it gets toggled to NFSv3. > > well, I tried doing a: > mount -u -o nfsv3 / It used to work when it was in /etc/fstab, when going from read-only to read-write, from what I recall. > on the system and this didn't work switch over to v3, it was still on > v2.. > > I haven't specified nfsv3 in /etc/fstab, but IMO, this should be the > default.. Since NFSv3 is the default, it might not need to be explicit. I can't recall. > > Also, I'm right now booting single user mode, because I'm -mapall to > a user, and lots of FreeBSD breaks when files aren't uid 0, and there > doesn't appear to be a way to remap the uid to root (that I have found).. Yep. It would take effect when going multi-user. "-mapall=root", although that is not a recommended security setting. Why don't you just allow the client to use whatever uid it would normally use instead of "-mapall"? > > > The other issue that I ran into is that NFSv2 can't access >4GB files > > > (or create them). > > As above, NFSv2 uses 32bit sizes. > > > > > Anyone object to adding BOOTP_NFSV3 to GENERIC? > > Well, that option only works when used with BOOTP_NFSROOT. > > The GENERIC configs for amd64, arm64,... use the other way. > > (Just to make it confusing, there are two different ways an NFS root > > fs is set up.) > > See below. > > > > > Or maybe making it a > > > tunable that defaults to set, because it seems a bit crazy to default > > > to v2 these days. > > I don't think changing the default to NFSv3 will be a problem. > > The reason it was NFSv2 was that, > > for some non-FreeBSD NFS servers, the NFSv3 file handle is different > > than the NFSv2 one. > > > > I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every > > system should be running the newer NFS code in the loader and be able > > to do NFSv3 booting. > > > > > This option was added in 432aad0e in 1997 so that the nfs_diskless > > > structure didn't need to be filled out. Does anything even > > > populate/fill it out anymore? I saw code in i386/i386/locore.s that > > > does this, but it doesn't appear anywhere else. > > Yes. For "options NFS_ROOT" (the other way), the loader uses > > "stand/libsa/nfs.c" to acquire the remote file system's root file handle > > and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.) > > Looking at it, it appears to enable NFSv3 so long as it finds > > "boot.nfsroot.nfshandlelen" set. > > Well, I'm not seeing that, and this system is booting via > pxeboot+loader, so maybe something is broken? If it's an up to date (within last 10+ years then, yes, it sounds like it might be broken. However, I'm not a loader guy... You can set it manually at the loader prompt to "28" and then see if it boots are is running NFSv3. I have no way of testing/debugging this. Maybe you can figure out why the loader isn't setting "boot.nfsroot.nfshandlelen" to 28? > > > There also appears to possibly be a way via mount options, but I can't > > > see where it's documented to set them. > > I think you just specify "nfsv3" as a mount option in the root fs > > line in /etc/fstab on the root fs on the NFS server. > > See above, this doesn't appear to work, or doesn't work the way I think > it should... Well, maybe I just don't recall correctly. > > > I don't think changing the default to NFSv3 will be a problem. > > The hassle is testing the various cases, to make sure nothing > > breaks. I have no diskless setup to do testing and I don't even know > > when installs/upgrades actually replace the loader? > > Well, this diskless was easier to setup than I expected, partly > because I already had most of the infrastructure together (from > netbooting another machine). Put pxeboot on a tftp server, configure > the dhcp server to send the correct
Re: NFSv4 on MacOS Monterey
Adonis Peralta wrote: > I have some NFSv4 (sec=sys) shares on FreeBSD 13.1 which I'm trying to > connect correctly with MacOS 12.4 > Monterey. > I got the basics down but don't think I have permissions and extended > attributes working correctly. Well, here are a few comments. Note that I haven't used Mac OSX in over a decade, so I don't remember much of anything about it. > My configuration is as follows: > > SERVER CONFIGURATION > > OS: FreeBSD 13.1 > > === > /etc/rc.conf > # NFS Configuration > nfs_server_enable="YES" > nfs_server_flags="-u -t -n 4" 4 is very small, although that will only be a performance issue. > mountd_enable="YES" Since you have specified nfsv4_server_only, mountd will be configured correctly (using the -R), so this line is not needed (although I don't thing it will cause trouble). > ### mountd_flags="-R" > ### rpcbind_enable="YES" > ### rpc_lockd_enable="YES" >### rpc_statd_enable="YES" > # Enable NFSv4 > nfsv4_server_enable="YES" > nfsv4_server_only="YES" > nfsuserd_enable="YES" > nfsuserd_flags="-domain rambo.lan" > === > > === > /etc/exports > # Exports Configuration > /drivepool/backups -alldirs -mapall=adonis:wheel > /drivepool/media -alldirs -mapall=adonis:wheel > /drivepool/home/adonis -alldirs -mapall=adonis:wheel > /drivepool/public -mapall=adonis:wheel These lines mean that the uid/gids in the RPC headers will be ignored and all RPCs will be done as whatever uid is assigned to "adonis" in the server's password database. > V4: /drivepool adonis-mbp adonis-pc > === > > === > /etc/sysctl.conf > # Asks nfsd to convert remote uids/gid encoded as numeric strings to be > mapped to an actual uid/gid > vfs.nfsd.enable_stringtouid=1 You probably do not want this. Since you are running nfsuserd, it will be mapping between the client uid/gid <-> the names for the Getattr/Setattr. If the Mac OSX client does not have "adonis" in its password database, that will be a problem. (These mappings have nothing to do with the uid/gids in the RPC header. The latter is used to set the credentials for the RPC against the server. In your case, completely ignored. The name<->uid/gid mappings are used for Setattr/Getattr. Things like "chmod", "stat"...) > # Applies to both nfs server and client. Asks client/server to send numeric > strings for uid/gid. > ### vfs.nfs.enable_uidtostring=0 For a server, you either set both of the above to 1 and do not run the nfsuserd or set both of the above to 0 and set them both to 0. I do not know if Mac OSX knows how to do the "uid/gid" in the string for Getattr/Setattr, That is what you are doing when the above are set to 1 and is the default for Linux, plus works for FreeBSD so long as you are not using Kerberized mounts. (To know, you would need to look a Setattr RPC done by the Mac OSX client in wireshark for either "chgrp" or "chown" and see how the Owner/Owner_Group string is formatted. A number or a "name@domain".) > vfs.nfsd.debuglevel=3 > === > > The directories above are hosted on ZFS and nfs4 acls support is turned on. > > CLIENT CONFIGURATION > > OS: MacOS 12.4 Monterey > > === > nfs.client.mount.options=vers=4.0,intr,namedattr Named attributes are not supported by the FreeBSD server and won't work. > nfs.client.default_nfs4domain = rambo.lan > === > > Note: above I'm using namedattr to try to get the client to connect with > named attributes support. As above, named attributes won't work. > RESULTS > > What I see when I connect via finder is the following: > > 1. I am able to read/write to the shares since /etc/exports contains the > -mapall line, yet inspecting a packet > trace shows me: > > === > packet #1 > --- > client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR > Opcode: PUTFH (22) > Opcode: ACCESS (3), [Check: RD LU MD XT DL XE] > Opcode: GETATTR (9) > > packet #2 > --- > server ip -> client ip Operations (count: 3) > Opcode: PUTFH (22) > Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], [Allowed: > RD LU] > Status: NFS4_OK (0) > Supported types (of requested): 0x1f >Access rights (of requested): 0x03 > ...1 = 0x001 READ: allowed > ..1. = 0x002 LOOKUP: allowed > .0.. = 0x004 MODIFY: *Access Denied* > 0... = 0x008 EXTEND: *Access Denied* >...0 = 0x010 DELETE: *Access Denied* This is saying that the uid for "adonis" on the server does not have write access to the file. > Opcode: GETATTR (9) > === > > Why is MD, XT, DL coming up as Access Denied if I can read/write to the share? Hmm, not sure. If you were to show all the reply fields for the Getattr, then I could probably guess. It might be Owner (is it "ado...@rambo.lan"). it could be ACLs. To check those, you should be able to do whatever the Mac OSX equivalent to getfacl is. > I have a feeling this is because UID/GID mapping is not happening correctly. > I can see in the packet trace >that FreeBSD's `nfsd` is sending some > credentials as
NFSv4 on MacOS Monterey
I have some NFSv4 (sec=sys) shares on FreeBSD 13.1 which I'm trying to connect correctly with MacOS 12.4 Monterey. I got the basics down but don't think I have permissions and extended attributes working correctly. My configuration is as follows: SERVER CONFIGURATION OS: FreeBSD 13.1 === /etc/rc.conf # NFS Configuration nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_enable="YES" ### mountd_flags="-R" ### rpcbind_enable="YES" ### rpc_lockd_enable="YES" ### rpc_statd_enable="YES" # Enable NFSv4 nfsv4_server_enable="YES" nfsv4_server_only="YES" nfsuserd_enable="YES" nfsuserd_flags="-domain rambo.lan" === === /etc/exports # Exports Configuration /drivepool/backups -alldirs -mapall=adonis:wheel /drivepool/media -alldirs -mapall=adonis:wheel /drivepool/home/adonis -alldirs -mapall=adonis:wheel /drivepool/public -mapall=adonis:wheel V4: /drivepool adonis-mbp adonis-pc === === /etc/sysctl.conf # Asks nfsd to convert remote uids/gid encoded as numeric strings to be mapped to an actual uid/gid vfs.nfsd.enable_stringtouid=1 # Applies to both nfs server and client. Asks client/server to send numeric strings for uid/gid. ### vfs.nfs.enable_uidtostring=0 vfs.nfsd.debuglevel=3 === The directories above are hosted on ZFS and nfs4 acls support is turned on. CLIENT CONFIGURATION OS: MacOS 12.4 Monterey === nfs.client.mount.options=vers=4.0,intr,namedattr nfs.client.default_nfs4domain = rambo.lan === Note: above I'm using namedattr to try to get the client to connect with named attributes support. RESULTS What I see when I connect via finder is the following: 1. I am able to read/write to the shares since /etc/exports contains the -mapall line, yet inspecting a packet trace shows me: === packet #1 --- client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR Opcode: PUTFH (22) Opcode: ACCESS (3), [Check: RD LU MD XT DL XE] Opcode: GETATTR (9) packet #2 --- server ip -> client ip Operations (count: 3) Opcode: PUTFH (22) Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], [Allowed: RD LU] Status: NFS4_OK (0) Supported types (of requested): 0x1f Access rights (of requested): 0x03 ...1 = 0x001 READ: allowed ..1. = 0x002 LOOKUP: allowed .0.. = 0x004 MODIFY: *Access Denied* 0... = 0x008 EXTEND: *Access Denied* ...0 = 0x010 DELETE: *Access Denied* Opcode: GETATTR (9) === Why is MD, XT, DL coming up as Access Denied if I can read/write to the share? I have a feeling this is because UID/GID mapping is not happening correctly. I can see in the packet trace that FreeBSD's `nfsd` is sending some credentials as `ado...@rambo.lan`, but MacOS's nfs client is sending uid 501 and gid 20 for my user in the RPC credentials. I don't see how `nfsd` will be able to map uid 501, gid 20 to the server's uid and gid and instead I was expecting `ado...@rambo.lan` to be sent for credentials from the client side. The link below tells me that this is an inherent issue with NFSv4? https://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+with+AUTH_UNIX 2. Extended attributes don't work at all. Here is the result: === $ cd /Volumes/media $ touch test.txt $ xattr -w com.example.color blue test.txt # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # === -- Adonis
Re: make NFSv3 default now on diskless
Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +: > John-Mark Gurney wrote: > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > up having issues because by default, NFS root is only v2. > > > > One of things that happened was disk space available was listed as > > -138G, or -144830429K. I assume this is because the server is reporting > > TBs instead. > Yes. NFSv2 uses 32bit sizes. Should we make the NFS server clamp various sizes then? instead of reporting negative numbers? (Sorry if this is already done on newer versions of FreeBSD, my server is a bit old.) > > If I mount via mount_nfs, the sizes are normal/correct because it mounts > > v3. > I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on the > remote root fs. Then, when the system does a "mount -u" to make it > read/write it gets toggled to NFSv3. well, I tried doing a: mount -u -o nfsv3 / on the system and this didn't work switch over to v3, it was still on v2.. I haven't specified nfsv3 in /etc/fstab, but IMO, this should be the default.. Also, I'm right now booting single user mode, because I'm -mapall to a user, and lots of FreeBSD breaks when files aren't uid 0, and there doesn't appear to be a way to remap the uid to root (that I have found).. > > The other issue that I ran into is that NFSv2 can't access >4GB files > > (or create them). > As above, NFSv2 uses 32bit sizes. > > > Anyone object to adding BOOTP_NFSV3 to GENERIC? > Well, that option only works when used with BOOTP_NFSROOT. > The GENERIC configs for amd64, arm64,... use the other way. > (Just to make it confusing, there are two different ways an NFS root > fs is set up.) > See below. > > > Or maybe making it a > > tunable that defaults to set, because it seems a bit crazy to default > > to v2 these days. > I don't think changing the default to NFSv3 will be a problem. > The reason it was NFSv2 was that, > for some non-FreeBSD NFS servers, the NFSv3 file handle is different > than the NFSv2 one. > > I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every > system should be running the newer NFS code in the loader and be able > to do NFSv3 booting. > > > This option was added in 432aad0e in 1997 so that the nfs_diskless > > structure didn't need to be filled out. Does anything even > > populate/fill it out anymore? I saw code in i386/i386/locore.s that > > does this, but it doesn't appear anywhere else. > Yes. For "options NFS_ROOT" (the other way), the loader uses > "stand/libsa/nfs.c" to acquire the remote file system's root file handle > and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.) > Looking at it, it appears to enable NFSv3 so long as it finds > "boot.nfsroot.nfshandlelen" set. Well, I'm not seeing that, and this system is booting via pxeboot+loader, so maybe something is broken? > > There also appears to possibly be a way via mount options, but I can't > > see where it's documented to set them. > I think you just specify "nfsv3" as a mount option in the root fs > line in /etc/fstab on the root fs on the NFS server. See above, this doesn't appear to work, or doesn't work the way I think it should... > I don't think changing the default to NFSv3 will be a problem. > The hassle is testing the various cases, to make sure nothing > breaks. I have no diskless setup to do testing and I don't even know > when installs/upgrades actually replace the loader? Well, this diskless was easier to setup than I expected, partly because I already had most of the infrastructure together (from netbooting another machine). Put pxeboot on a tftp server, configure the dhcp server to send the correct options, extract base.txz to a directory, export it, and it worked. I assume that I'm getting loader from that install since I don't specify it in the dhcp server. As for testing, we have the CI system for that, right? ;p /me needs to get back to work on the lab. I guess we'd need to list the configurations that we care about, the only ones I can think of, off the top of my head are pxeboot (which I'm testing now), and u-boot.. For servers, are there any servers that are NFSv2 only that are in common use today? If you're running an ancient server that is NFSv2 only, I think you deserve to have to rebuild kernels or something instead of making 99% of the rest of us do it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
[Bug 263445] [tcp] Fatal trap 12: page fault while in kernel mode // supervisor read data, page not present // 13.1-RC3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445 --- Comment #11 from Michael Tuexen --- (In reply to Igor A. Valkov from comment #6) Hi Igor, we discussed this bug on todays transport call. Two questions: 1. Can you make also core files against 13.1 RELEASE available? 2. Would you be willing to and able to run a custom kernel? We might want to provide a kernel which allows to get more data on the situation under which the problem occurs. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263445] [tcp] Fatal trap 12: page fault while in kernel mode // supervisor read data, page not present // 13.1-RC3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445 --- Comment #10 from Michael Tuexen --- (In reply to Michael Tuexen from comment #9) The confusion was on my part by using a 13.1 RELEASE kernel instead of a 13.1R3 kernel. -- You are receiving this mail because: You are the assignee for the bug.
Re: make NFSv3 default now on diskless
Rick Macklem wrote: > John-Mark Gurney wrote: > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > up having issues because by default, NFS root is only v2. > > > > One of things that happened was disk space available was listed as > > -138G, or -144830429K. I assume this is because the server is reporting > > TBs instead. > Yes. NFSv2 uses 32bit sizes. > > > If I mount via mount_nfs, the sizes are normal/correct because it mounts > > v3. > I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on the > remote root fs. Then, when the system does a "mount -u" to make it > read/write it gets toggled to NFSv3. > > > The other issue that I ran into is that NFSv2 can't access >4GB files > > (or create them). > As above, NFSv2 uses 32bit sizes. > > > Anyone object to adding BOOTP_NFSV3 to GENERIC? > Well, that option only works when used with BOOTP_NFSROOT. > The GENERIC configs for amd64, arm64,... use the other way. > (Just to make it confusing, there are two different ways an NFS root > fs is set up.) > See below. > > > Or maybe making it a > > tunable that defaults to set, because it seems a bit crazy to default > > to v2 these days. > I don't think changing the default to NFSv3 will be a problem. > The reason it was NFSv2 was that, > for some non-FreeBSD NFS servers, the NFSv3 file handle is different > than the NFSv2 one. > > I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every > system should be running the newer NFS code in the loader and be able > to do NFSv3 booting. > > > This option was added in 432aad0e in 1997 so that the nfs_diskless > > structure didn't need to be filled out. Does anything even > > populate/fill it out anymore? I saw code in i386/i386/locore.s that > > does this, but it doesn't appear anywhere else. > Yes. For "options NFS_ROOT" (the other way), the loader uses > "stand/libsa/nfs.c" to acquire the remote file system's root file handle > and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.) > Looking at it, it appears to enable NFSv3 so long as it finds > "boot.nfsroot.nfshandlelen" set. Just to give you a little more on how these two methods work (from my vague recollection..): options NFS_ROOT - Something (usually PXEBOOT) loaded the loader. - The loader filled in some environment variables using the code in stand/libsa/nfs.c. boot.nfsroot.nfshandle - The root fs file handle boot.nfsroot.nfshandlelen - The length of above (if not set, use NFSv2) - plus some others to set up the network interface - The kernel uses these environment variables to fill in nfs_diskless or nfsv3_diskless. This is done by the function called nfs_setup_diskless(), found in sys/nfs/nfs_diskless.c. options BOOTP_NFSROOT - Kernel gets loaded somehow. - Kernel uses code in sys/nfs/bootp_subr.c to get the information needed (such as the root fs file handle) via BOOTP/DHCP. For this one, it will use NFSv2 unless "options BOOTP_NFSV3" was specified along with "options BOOTP_NFSROOT" in the kernel config. If you are using the "NFS_ROOT" approach, I am surprised that you get NFSv2, since the code in stand/libsa/nfs.c appears to do NFSv3 now and sets "boot.nfsroot.nfshandlelen", unless I am mis-reading it? - Maybe you can pop out into the loader and look at the environment variables with "show"? rick > There also appears to possibly be a way via mount options, but I can't > see where it's documented to set them. I think you just specify "nfsv3" as a mount option in the root fs line in /etc/fstab on the root fs on the NFS server. I don't think changing the default to NFSv3 will be a problem. The hassle is testing the various cases, to make sure nothing breaks. I have no diskless setup to do testing and I don't even know when installs/upgrades actually replace the loader? rick -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Re: make NFSv3 default now on diskless
John-Mark Gurney wrote: > I just booted FreeBSD-current diskless, using NFS root, and I ended > up having issues because by default, NFS root is only v2. > > One of things that happened was disk space available was listed as > -138G, or -144830429K. I assume this is because the server is reporting > TBs instead. Yes. NFSv2 uses 32bit sizes. > If I mount via mount_nfs, the sizes are normal/correct because it mounts > v3. I believe most specify "nfsv3" in the "/" mount line of /etc/fstab on the remote root fs. Then, when the system does a "mount -u" to make it read/write it gets toggled to NFSv3. > The other issue that I ran into is that NFSv2 can't access >4GB files > (or create them). As above, NFSv2 uses 32bit sizes. > Anyone object to adding BOOTP_NFSV3 to GENERIC? Well, that option only works when used with BOOTP_NFSROOT. The GENERIC configs for amd64, arm64,... use the other way. (Just to make it confusing, there are two different ways an NFS root fs is set up.) See below. > Or maybe making it a > tunable that defaults to set, because it seems a bit crazy to default > to v2 these days. I don't think changing the default to NFSv3 will be a problem. The reason it was NFSv2 was that, for some non-FreeBSD NFS servers, the NFSv3 file handle is different than the NFSv2 one. I added NFSv3 support to stand/libsa/nfs.c about 15years ago, so every system should be running the newer NFS code in the loader and be able to do NFSv3 booting. > This option was added in 432aad0e in 1997 so that the nfs_diskless > structure didn't need to be filled out. Does anything even > populate/fill it out anymore? I saw code in i386/i386/locore.s that > does this, but it doesn't appear anywhere else. Yes. For "options NFS_ROOT" (the other way), the loader uses "stand/libsa/nfs.c" to acquire the remote file system's root file handle and fills it in. (See nfs_setup_diskless() in sys/nfs/nfs_diskless.c.) Looking at it, it appears to enable NFSv3 so long as it finds "boot.nfsroot.nfshandlelen" set. > There also appears to possibly be a way via mount options, but I can't > see where it's documented to set them. I think you just specify "nfsv3" as a mount option in the root fs line in /etc/fstab on the root fs on the NFS server. I don't think changing the default to NFSv3 will be a problem. The hassle is testing the various cases, to make sure nothing breaks. I have no diskless setup to do testing and I don't even know when installs/upgrades actually replace the loader? rick -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
[Bug 263445] [tcp] Fatal trap 12: page fault while in kernel mode // supervisor read data, page not present // 13.1-RC3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445
--- Comment #9 from Michael Tuexen ---
(In reply to Richard Scheffenegger from comment #8)
Hi Richard,
I'm looking at the tracefile provided by Igor and see:
(kgdb) f 10
#10 0x80dd7eed in tcp_do_segment (m=, th=, so=, tp=0xfe025fb86518, drop_hdrlen=52,
tlen=, iptos=0 '\000') at
/usr/src/sys/netinet/tcp_input.c:2637
2637(void)
tp->t_fb->tfb_tcp_output(tp);
(kgdb) p tp->t_state
$10 = 6
(kgdb) p *tp->sackhint.nexthole
$11 = {start = 1529400226, end = 1529409856, rxmit = 1529409855, scblink =
{tqe_next = 0x0, tqe_prev = 0xfe025fb86658}}
(kgdb)
Do you really see 8 as the state (which is TCPS_LAST_ACK)? I see 6 (which is
TCPS_FIN_WAIT_1).
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 263445] [tcp] Fatal trap 12: page fault while in kernel mode // supervisor read data, page not present // 13.1-RC3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263445 Michael Tuexen changed: What|Removed |Added Summary|Fatal trap 12: page fault |[tcp] Fatal trap 12: page |while in kernel mode // |fault while in kernel mode |supervisor read data, page |// supervisor read data, |not present // 13.1-RC3 |page not present // ||13.1-RC3 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260393] [tcp] Page Fault tcp_output/tcp_input
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260393 Michael Tuexen changed: What|Removed |Added Summary|Page Fault |[tcp] Page Fault |tcp_output/tcp_input|tcp_output/tcp_input -- You are receiving this mail because: You are the assignee for the bug.
