From nobody Wed Mar 27 00:33:55 2024 X-Original-To: freebsd-fs@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 4V472r4jl0z5G6Mj for ; Wed, 27 Mar 2024 00:34:12 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4V472r2yHgz4TJ8 for ; Wed, 27 Mar 2024 00:34:12 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2a072747fc6so1674181a91.2 for ; Tue, 26 Mar 2024 17:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711499650; x=1712104450; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mQ6T+dBI6V01s1ZJAQGuaDelK8oPUwKKqz2HlXBRJC8=; b=OxjLsTewlbnlgugIongiqsxRWyJ8dQvDmYzt+loHS8uNiU7qzHijDAg7lQw/4xxaN6 rXo3m2vqqOy4+lOB4B5HghQtsBrBf8HeBqiQTiSFmquwwU7PX6tchNpOvdxBXC7bN8qs 3XHYHNLntX0F+bLf8SnSKIgAvKQOYMkZeX/tW9XGROZX/JhpeHnHf5UFE/kiWHvOfYIR LBbQrFcxPsruvw5k94B5ReCUegn8mkcdhf+dHAdIQEoi4ak0bAaxBDqN5mekvxl2op84 EgEoJ+4peuGCmmSQdaMxc2zxI7GFIjVqTo2furCelUJlSoxDHktWk5XwbjHMJlvOP7Vq 3pLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711499650; x=1712104450; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mQ6T+dBI6V01s1ZJAQGuaDelK8oPUwKKqz2HlXBRJC8=; b=EJlYXrzS/KLkWIB97ba5dy02hW3UWBjPjH8uDl+AyNLnAGeTRmx7MM0hwqpvXgppwv QYxZ7lj2wLnZPAZ5gdFGVNqMjw+9XDbBp8qYz0oZkiYfu0SjWZHKcB59xnPTQnW+VmmD sBcA1TqBOMIeCU2knpG5VrAgMElQuz20Mu2/irqg06NhrUybJfEWyj/HvkpdwxB14h5o 9JUNTOUnavcVGgJyi9WA/bojttIEPSPQrigJKLrHn4IFY16W5eldO+IJDK9kIKludtu8 eYcbPKamJL/lg2FGhfQCQRckZ1fivGlHgxtzBgkZ0VS82/bFIa1olVzo4sY8faWoHJRD S+5w== X-Gm-Message-State: AOJu0YxynZBTzRMMZe6Ms8FRG0pMmVksTtY9dynT6EqcGiyk80Zfm06s 1E9w1ISt2FA33itQtaFZNpQwoNHkWdtUgIwr4stFrNychWqH9SUZ54eeA2S6vZilwx/NZrLpMue ixej1KUo16cIayvAPrIx+N2947rEbibY= X-Google-Smtp-Source: AGHT+IGXDZFZ7VbRfevYeyt++WIFdteZFP6BxNjySwg7EVczOzdRBKHxvI3WcnTpwFoSJ7ehRiHNY+rHtDgVTFbH53Q= X-Received: by 2002:a17:90a:c8:b0:29d:d8ca:74f1 with SMTP id v8-20020a17090a00c800b0029dd8ca74f1mr1335923pjd.14.1711499650264; Tue, 26 Mar 2024 17:34:10 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Tue, 26 Mar 2024 17:33:55 -0700 Message-ID: Subject: Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access To: Andreas Kempe Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V472r2yHgz4TJ8 On Tue, Mar 26, 2024 at 5:04=E2=80=AFPM Andreas Kempe wrote: > > Hello everyone, > > I have a bit of a head scratcher and need some help. I've configured a > Linux NFS server running on Rocky Linux 8, kernel version 6.8, to act > as a kerberised NFSv4 server. > > The server has the following export line > > /tank/beta-testing *.lysator.liu.se(rw,sync,no_wdelay,sec=3Dkrb5:= krb5p,no_root_squash) > > and I can mount the export fine using both krb5 and krb5p. idmap is > running on the Linux server/clients while nfsuserd is running on the > FreeBSD client. I'm using host credentials for the mounts and not user > credentials. > > I can mount the share on my Linux clients and everything works as > expected. > > On my FreeBSD clients, I have the issue that all users on the client > seem to get mapped to nobody when accessing files. Doing a directory > listing shows correct owners > > kempe@claptrap /mnt> ls -l /mp/diskus/ > total 92 > drwxr-xr-x 2 aoh aoh 2 feb. 18 22:35 aoh/ > drwxr-xr-x 195 hx hx 516 juli 1 2018 hx/ > drwx------ 3 kempe kempe 3 mars 27 00:45 kempe/ > drwxr-xr-x 104 octol lysator 213 maj 6 2022 octol/ > > and I can see that nfsuserd has loaded the info into the kernel > > 15 Mar 26 23:35:40 claptrap nfsuserd:[3097]: Added uid=3D31490 name=3Dk= empe > 16 Mar 26 23:35:40 claptrap nfsuserd:[3096]: Added uid=3D31490 name=3Dk= empe > > but if I try to enter the kempe directory, I get a permission denied > > kempe@claptrap /mnt> cd /mp/diskus/kempe > cd: Permission denied: '/mp/diskus/kempe' > > changing permissions on the kempe directory to 777, I can enter it and > create a file > > kempe@claptrap /mnt> cd /mp/diskus/kempe > kempe@claptrap /m/d/kempe> touch testfile > kempe@claptrap /m/d/kempe> ls -l > total 10 > drwxr-xr-x 5 kempe kempe 88 feb. 19 13:33 bonnie++-2.00a/ > -rw-r--r-- 1 nobody nobody 0 mars 27 00:54 testfile > > but the file is owned by nobody instead of my user kempe. > > User credentials are stored in LDAP and resolved through nslcd. > > I have tried searching, but this is a difficult one to search for as > most hits relate to everything being owned by nobody on account of > idmapd/nfsuserd not running. > > Has anyone seen anything like this or do you have any good suggestions > on where to start looking? Take a look at a packet capture in wireshark. Check that the @domain part of Owner and Owner_group attributes are the same and it is not a string of digits. If the domain is not the same, you can use the -domain command line option on nfsuserd to set it. (Since this "domain" is underdefined, I'd suggest only ascii characters and all alphabetics in lower case.) If the client sends a string of digits, check to make sure the sysctl vfs.nfs.enable_uidtostring is set to 0. rick > > Best regards, > Andreas Kempe >