From nobody Thu Jun 02 22:16:06 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7E77F1B6FBD7 for ; Thu, 2 Jun 2022 22:16:08 +0000 (UTC) (envelope-from donileo@gmail.com) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDgMW5jSnz4qCv for ; Thu, 2 Jun 2022 22:16:07 +0000 (UTC) (envelope-from donileo@gmail.com) Received: by mail-qv1-xf35.google.com with SMTP id a9so4496454qvt.6 for ; Thu, 02 Jun 2022 15:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JY7mAK4rHjPcJTjBn0QB590CfZZ5QSOU84mI1Mf/Nfo=; b=C9FFSQMGPVDE9X1kw+uAGepBxCgVBxOkUTgoVHg1Qphb2af9+IWoopoqq37uWYNZIp RSNUxj6XZEnJppnp0nNMMvDHF/tXwLNSd/kvrty9aOtxbaDzzqbvMRh64Tu2XHJcKtHz Zb2macjuxy8CwZ20KNjS9IgVmgng4viL57NgIlRRsAai03Wa+cjmq3bKSXxnmnoxM11Y Z2PIJ430kSpp/Yc7yAAmwkS6Zfdp10b+Gpz+5xpJwd12HkbVi/9T0fiF7J24oVFsPAL6 MX/e+RqIQPtfPQPl7s4RmB/s4QYUxWLu4VHzO8bBOnF5zStF9Vsa73MriE/idFtZcYNz y6fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JY7mAK4rHjPcJTjBn0QB590CfZZ5QSOU84mI1Mf/Nfo=; b=UnAYTVPQn6dKpbfK8+9dqrbQcB4ItugH2gPn/xvET2YW88HheraIb5vR1nyEFnMzwG v169zMmRuxlhvclQYXgddgsAlJ2FsiJN9b6Qqpwd2wtDtRnFCqcObatINVIiCrEWxgoi czKBhfccqzfTlufbQPOpMGB/bMemN9qKgIZI1ImilLHjP1sH2ElfMvAVpUGINm8aet9N n6D3gB8fbGJYFBIQHYEApi1TBCHtBjZJ7dAAaWxPgOsgSeUztory0DM0VmK906Dnupe7 7X678krp4d5+PrsxFN4vQnwjQkimpgU7Ppbdaw8kYq/0biGFf6myXcDH+rRPxT5OgAtr cZ6Q== X-Gm-Message-State: AOAM532au6RGOFSM3AKgbcLs8fryVzUBlbzp0AtJ7wgkvKa1bb0ChDct w54W8hHpJVpQc+dUWXDRZ0M= X-Google-Smtp-Source: ABdhPJwWd2gGuIrPU2Fl2Vc9VwpFPNa5/kppumjYY/Au9bmMtBnJZuHSezo5KKIfLmqz5CUEdRckZA== X-Received: by 2002:a0c:b392:0:b0:461:e7fa:2c0f with SMTP id t18-20020a0cb392000000b00461e7fa2c0fmr60185283qve.114.1654208167200; Thu, 02 Jun 2022 15:16:07 -0700 (PDT) Received: from [192.168.1.4] (pool-70-21-209-78.nwrk.east.verizon.net. [70.21.209.78]) by smtp.gmail.com with ESMTPSA id q188-20020ae9dcc5000000b0069fc13ce1f2sm4101216qkf.35.2022.06.02.15.16.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2022 15:16:06 -0700 (PDT) From: Adonis Peralta To: Rick Macklem Cc: freebsd-net@freebsd.org Subject: Re: NFSv4 on MacOS Monterey Date: Thu, 02 Jun 2022 18:16:06 -0400 X-Mailer: MailMate (1.14r5898) Message-ID: In-Reply-To: References: <5B070ACE-9ECD-4FAA-A975-C77BE87CEFAA@gmail.com> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LDgMW5jSnz4qCv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=C9FFSQMG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of donileo@gmail.com designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=donileo@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; R_MISSING_CHARSET(2.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[70.21.209.78:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from]; MLMMJ_DEST(0.00)[freebsd-net]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> mountd_enable=3D"YES" > Since you have specified nfsv4_server_only, mountd will be configured c= orrectly (using the -R), > so this line is not needed (although I don't thing it will cause troubl= e). Got it. >> My configuration is as follows: >> >> SERVER CONFIGURATION >> >> OS: FreeBSD 13.1 >> >> =3D=3D=3D >> /etc/rc.conf >> # NFS Configuration >> nfs_server_enable=3D"YES" >> nfs_server_flags=3D"-u -t -n 4" > 4 is very small, although that will only be a performance issue. Increased to 12. >> =3D=3D=3D >> /etc/sysctl.conf >> # Asks nfsd to convert remote uids/gid encoded as numeric strings to b= e mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=3D1 > 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, c= ompletely 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 /e= tc/passwd on MacOS states: =3D=3D=3D ## # User Database # # Note that this file is consulted directly only when the system is runni= ng # 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. ## =3D=3D=3D I believe there shouldn't be a problem because as I state a little down b= elow 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 b= e mapped to an actual uid/gid >> vfs.nfsd.enable_stringtouid=3D1 > 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, c= ompletely 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 nu= meric strings for uid/gid. >> ### vfs.nfs.enable_uidtostring=3D0 > 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 t= o do the "uid/gid" in > the string for Getattr/Setattr, That is what you are doing when the abo= ve 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 clie= nt 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 nam= e strings for OWNER and OWNER_GROUP in the following format "adonis@rambo= =2Elan for OWNER" and "wheel@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: >> =3D=3D=3D >> $ cd /Volumes/media >> $ touch test.txt >> $ xattr -w com.example.color blue test.txt >> >> # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # >> =3D=3D=3D > Yep, as noted above, they aren't supported and will not work. FreeBSD u= ses the Linux style extended > attribute model, not the resource fork/subfile one that Mac OSX and Sol= aris use. > Is this still the case if the shares are on ZFS? Is there any info on whe= n or if FreeBSD will get namedattr support? -- = Adonis