Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Alan Maxwell <amaxwell@fedex.com>
To:     Benjamin Coddington <bcodding@redhat.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: RE: [EXTERNAL] nfsv4 client idmapper issue
Thread-Topic: [EXTERNAL] nfsv4 client idmapper issue
Thread-Index: AQHYzoyLB0ZCEFrXiEO+WVUdCpVZ7K3rfeBggAAHfgCAAAJzcA==
Date:   Thu, 22 Sep 2022 14:50:03 +0000
Message-ID: <DS0PR12MB6486A843F54547C497E6064AC84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
References: <DS0PR12MB6486987EC76AD88C7A80D229C84F9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <46FAEBBD-50BC-464B-A983-1DC2232795C5@redhat.com>
 <DS0PR12MB6486B941F1EA96D2634CED63C84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <812A1C59-B489-4D6B-8673-15F5C86A99D0@redhat.com>
 <DS0PR12MB648637C3D4E07C6FCA90A0E4C84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <CA53F1A0-807D-4297-9E1E-75E4AA26D470@redhat.com>
In-Reply-To: <CA53F1A0-807D-4297-9E1E-75E4AA26D470@redhat.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?R/P4GZFcCsYmujduXTk69tZrGXkqDY32C6t4eRwGy6uZGK/fZaRaY++FzlbS?=
 =?us-ascii?Q?h33zO7o1+fVPMbHXm8T/r7m67FzcgRVtAMHNK1lhD6I0BTakE4ZLV4HtmzhR?=
 =?us-ascii?Q?yxHuE6m+BVLRBKV3QoaqXDYpnlxPymv09gao7z0eD+ILD8/rxMfauXdYaHVa?=
 =?us-ascii?Q?GHUj/uiZA59bB7N8FJjSmFnF/BQAxcpUo/X9AqeOn+BtUoQaN40EpccqVX6q?=
 =?us-ascii?Q?fZzPe9XZ0+MRSJ4f4ASyWRHRlP1xXCGGBGtJxIY0O+8mHpQ5AZzsLMjUZKhr?=
 =?us-ascii?Q?Z+qHVkFDj4u/DSrF1EDP1LofRi1ox17vOkvOA5V5tXvXhwFW4BAZgA8FWxj3?=
 =?us-ascii?Q?QDGLG4wk8Soj4ef1zkko9ID/9zVsijwiuz2myup51Yr4xppqYB4xzBVkxuOc?=
 =?us-ascii?Q?bvluKNkrwgHGaMFOeFaMEBMUk0bay6SGwJhAKUbzepVrfcLO142es49OVzPr?=
 =?us-ascii?Q?E/eJUo8Oam2zUDVCWJ1FP4QeQxypsRaLmO389SUnOlIGqxUxebF/xMMpMX+7?=
 =?us-ascii?Q?jVDol47zfixyfnoBFOvDXWDYKffjp15A9xf0DuoQuWwsJ8IVauxYTseAeN0d?=
 =?us-ascii?Q?9ruXlxYdeNuxe1WMBBfjLG/hCMcXEWnOnhks0/2/tlcuWht39PmHBKT1LM4N?=
 =?us-ascii?Q?CHDWshrwhqyaBGFKTN1YBjsuaQ5uaTWDDg5F1TaDJeOoeiK71gXIUcct5QsY?=
 =?us-ascii?Q?4DbHh2VV2hSdaPZAwmucH05Zzp98uLg/hmjDBdkfOiqz8xw8cu9N1IZ4eL75?=
 =?us-ascii?Q?IleS9mpIYmTNSY19nJW5tC4TjZoOUuuPrfndnD2PgVtE3zgxKI3pKiAxVyQO?=
 =?us-ascii?Q?zpPoAGknIeM2H79nziMxeF5ERDuzFMHie+RApQTrB35e08uGWaiOrUGLnjOq?=
 =?us-ascii?Q?F3QTPVFbf5PcWkKwFVI5TGHdyKrji9zX19g7GCJ+8KQe9jY3aSLaoPouoZw/?=
 =?us-ascii?Q?OabvkhRyicRbjb2uckpTtbK+zkM5Ol9YR7SHjHZdquflywETh7+GLK5dhaOA?=
 =?us-ascii?Q?Vlf1TCyo8HEgAJQ3ghR7H6H4E82QmRBkl86cKoDULtK5chtgAKEMQoCwT5n1?=
 =?us-ascii?Q?zyBOGvnt/Wne1syBFVy9vM2Z6chl9XIiZgcRxHi/0dELq9e3yA1W16MB92We?=
 =?us-ascii?Q?X7FTYvXkXur0AIDGdJrBMAd7QMUgxjQfJyWK5M3FzkBA6gHjKDJLXj/H9A17?=
 =?us-ascii?Q?hqU2TqwBUp+CcjpG4gDU5zNqXE88YtWb12SIL4SqqJIVgpZKqk9ps7RBf9eB?=
 =?us-ascii?Q?Ruuwi0ls7WVwKfKf5DlgLHX5Ru+8swGG42Lix9gIM0OI710jmhufS1qcaFN2?=
 =?us-ascii?Q?HDDVT/kGXQYedbPqqa7BcHrZlvVbiPGBdFC7ye9xCZ8MtLg7FJx7GMTSHTEX?=
 =?us-ascii?Q?JI2kCNfWZz2Nq1TRhIqjz6uExEOBhWHlfv7IfvKlEnZJABg0Fop8fpySF8n3?=
 =?us-ascii?Q?l45QLr+l5rgP5Jnvqry0jd6I7Tjp4OvetB/KCmWncXlm6i3ThrKmlxCWj1oV?=
 =?us-ascii?Q?ub0FrT0CXxjyZMICfARNkdedyfUjjTRWyOtH3uIlc8tkdJsjdBgLO3vcT2OJ?=
 =?us-ascii?Q?J53QeXw3EOllKlRkiKYlHapvSnd5nR1fylG0pAUN?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fedex.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB6486.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 459e2d15-1e8e-4f23-1179-08da9ca9bb83
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2022 14:50:03.5525
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b945c813-dce6-41f8-8457-5a12c2fe15bf
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QnprG4X4Bl4Nb6XdMzqWDo4GNT0z+7w3z4aeBCjI7lRk+G625bIzZt7ziRVHAgwiAkluzV8yXBTPUpRSuBtKbQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR12MB5460
X-Proofpoint-ORIG-GUID: kioAoxnUQVjSocjaPahHR-8-0BcuxU3j
X-Proofpoint-GUID: kioAoxnUQVjSocjaPahHR-8-0BcuxU3j
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-22_08,2022-09-22_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 mlxscore=0
 bulkscore=0 impostorscore=0 clxscore=1015 priorityscore=1501
 malwarescore=0 adultscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000
 definitions=main-2209220099
X-Spam-Status: No, score=-18.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,
        USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


-----Original Message-----
From: Benjamin Coddington <bcodding@redhat.com>=20
Sent: Thursday, September 22, 2022 9:40 AM
To: Alan Maxwell <amaxwell@fedex.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [EXTERNAL] nfsv4 client idmapper issue

On 22 Sep 2022, at 10:18, Alan Maxwell wrote:

> Again, we would expect ultimately if the server returns error, nfs=20
> client should do same, show and error, not change the configuration=20
> and ignore our disable_id_mapping.

Not all NFSv4 errors are sent back to userspace, and the meaning of this er=
ror ( I am assuming the server returns NFS4ERR_BADOWNER, a wire capture wou=
ld verify it ) is to tell the client that it was unable to translate the ow=
ner value.  As I understand RFC 8881, that's a clear indication to the clie=
nt that the server is not treating the values as numeric uid/gid, it is att=
empting to map them.  That is why the client changes its behavior.

Besides, what error can the chown syscall possibly return in this case?
Let's say the client /doesn't/ re-enable string-based names. What are you e=
xpecting the client to return to userspace?

I would expect chgrp to behave similar to a local file system:
chgrp badgroupname junk
chgrp: invalid group: 'badgroupname'


Ben