From owner-freebsd-fs@freebsd.org Tue May 3 06:27:36 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C81EFB2BE48 for ; Tue, 3 May 2016 06:27:36 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from mhost.tf.uni-kiel.de (mhost.tf.uni-kiel.de [134.245.247.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5313B1FCA for ; Tue, 3 May 2016 06:27:35 +0000 (UTC) (envelope-from juan@tf.uni-kiel.de) Received: from amavis.tf.uni-kiel.de (unknown [192.168.247.79]) by mhost.tf.uni-kiel.de (Postfix) with ESMTP id 49A69ED80EC for ; Tue, 3 May 2016 08:27:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at tf.uni-kiel.de Received: from mhost.tf.uni-kiel.de ([134.245.247.71]) by amavis.tf.uni-kiel.de (amavis.tf.uni-kiel.de [192.168.247.79]) (amavisd-new, port 10025) with ESMTP id L_CzUOyrBWYc for ; Tue, 3 May 2016 08:27:23 +0200 (CEST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mhost.tf.uni-kiel.de (Postfix) with ESMTPSA id 82473ED80DF for ; Tue, 3 May 2016 08:27:23 +0200 (CEST) Received: by mail-oi0-f44.google.com with SMTP id k142so13383246oib.1 for ; Mon, 02 May 2016 23:27:22 -0700 (PDT) X-Gm-Message-State: AOPr4FUV+7Dg/46A+ub+7ZE38CBN+CYvZpuc0OguVmNbyPIn1m7DrCvijKW0X9AU3tBAZ+v8RvXRycsS9557Wg== MIME-Version: 1.0 X-Received: by 10.157.42.199 with SMTP id e65mr241595otb.96.1462256841715; Mon, 02 May 2016 23:27:21 -0700 (PDT) Received: by 10.157.9.8 with HTTP; Mon, 2 May 2016 23:27:21 -0700 (PDT) In-Reply-To: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> References: <1208197890.85963163.1462233461385.JavaMail.zimbra@uoguelph.ca> Date: Tue, 3 May 2016 08:27:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Mounting FreeBSD NFSv4 share on Linux using krb5 From: Julian Andrej To: Rick Macklem Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 06:27:36 -0000 Thanks. I will try your suggestions. I got the mount working adding "-o vers=3" to the mount. But i have not enough experience to really figure out if the "handshake" worked. This way i can mount the share AND i need a user TGT to access the mount, so i guess this i correct? On Tue, May 3, 2016 at 1:57 AM, Rick Macklem wrote: > Julian Andrej wrote: >> Hello, >> >> i'm desperately trying to mount a nfsv4 export from FreeBSD on a Linux >> client using sec=krb5. >> >> So my setup is as follows: >> FreeBSD host which is the KDC. Linux client which can auth via >> kerberos and should be able to mount the nfs share. >> >> Mounting the share with sec=krb5 from FreeBSD on another FreeBSD box >> is no problem, but it fails on the linux client. The client fails with >> >> $ sudo mount -t nfs4 -o sec=krb5 ***:/tank/homes mnt -vv >> mount.nfs4: timeout set for Mon May 2 15:39:19 2016 >> mount.nfs4: trying text-based options 'sec=krb5,addr=***,clientaddr=***' >> mount.nfs4: mount(2): Input/output error >> mount.nfs4: mount system call failed >> >> and on the FreeBSD host i get the message >> >> gssd_pname_to_uid: failed major=0xd0000 minor=-1765328227 > The host based credential maps to "nobody", since it isn't in > the passwd database. I'm not sure, but I think that is all this > is saying (ie. not what is causing the mount to fail). > > Someone else discovered that a Linux client actually used krb5i even > when krb5 was specified. > --> Make sure the /etc/exports on the FreeBSD server specifies > sec=krb5i,krb5 (and not sec=krb5) > --> This will work around this issue. > - If you already have both krb5,krb5i specified in your /etc/exports > then I have no idea what the failure is. > - A first step is capturing packets (all of them and not just the > NFS ones) and then looking at them in wireshark. Hopefully that > will give you some idea where it is failing. > > Good luck. It can bvery difficult to figure out what is causing the > failure. Linux clients have been known to work, but I have no idea if > all/current ones do? > > rick > >> gssd_release_name: done major=0x0 minor=0 >> gssd_release_cred: done major=0x0 minor=0 >> >> which translates to KRB5_NO_LOCALNAME. I have the appropriate >> principals with nfs/* for the host and client! >> >> I have tried heimdal from base and MIT krb5 from ports. Both show the >> same behavior. >> >> The actual kernel log from linux is: >> Mai 02 15:37:19 *** kernel: NFS: nfs4_discover_server_trunking >> unhandled error -121. Exiting with error EIO >> >> Can anyone guide me to a possible solution here? >> >> Regards >> Julian >>