[Samba] nfs4 with Samba 4
Gémes Géza
geza at kzsdabas.hu
Sat Jan 28 23:32:20 MST 2012
2012-01-28 21:44 keltezéssel, steve írta:
> On 28/01/12 20:29, Gémes Géza wrote:
>> 2012-01-28 18:41 keltezéssel, steve írta:
>>> On 28/01/12 12:21, steve wrote:
>>>> On 28/01/12 11:03, Gémes Géza wrote:
>>> Summary:
>>>
>>> 1. kerberized /etc/exports
>>> /export gss/krb5(rw,fsid=0,insecure,no_subtree_check,async)
>>> /export/home gss/krb5(rw,nohide,insecure,no_subtree_check,async)
>>> then:
>>> mount -t nfs4 hh3:/home /mnt -o sec=krb5
>>> no write access
>>>
>>> 2. conventional /etc/exports
>>> /export *(rw,fsid=0,insecure,no_subtree_check,async)
>>> /export/home *(rw,nohide,insecure,no_subtree_check,async)
>>> then:
>>> mount -t nfs4 hh3:/home /mnt
>>> write access OK
>>>
>>> 3. kerberized variation on /etc/exports
>>> /export
>>> *(rw,fsid=0,crossmnt,insecure,no_subtree_check,async,sec=krb5)
>>> /export/home *(rw,insecure,no_subtree_check,async,sec=krb5)
>>> then:
>>> mount -t nfs4 hh3:/home /mnt -o sec=krb5
>>> no write access
>>>
>>> I have tried all combos of crossmnt and nohide
>>>
>>> idmapd seems to be mapping correctly and id<user> gives what getent
>>> gives
>>>
>>> Any ideas? Why does the kerberized mount not allow rw access?
>>> Steve
>>>
>>> Geza, do you think it's worth sticking this on samba technical?
>> To me it seems an nfs4 related problem so no samba-technical is not the
>> right place to ask
>> In the meantime please tell us a little more about your environment:
>> pam config
>> idmapd config
>> klist (of user) right after login, before trying to do anything on nfs
>> and after (e.g an ls)
>>
>> I'm not an nfs4 expert myself, but before migration (a few years ago) to
>> openafs I've had a working nfs4 gss/krb5 setup (it just kernel panic-ed
>> every other day, until I've got fed up and migrated away from it) maybe
>> I can remember.
>>
>> Regards
>>
>> Geza
> Hi again
>
> The share mounts rw conventionally but olnt ro when exported gss/krb5
> Here is the output and some files:
>
> /etc/pam.d/common-auth (the other pam files are OK and pam is working)
> auth required pam_env.so
> auth optional pam_gnome_keyring.so
> auth sufficient pam_unix2.so
> auth sufficient pam_krb5.so use_first_pass
> auth required pam_deny.so
>
> /etc/idmapd.conf
> [General]
> Verbosity=0
> Pipefs-Directory=/var/lib/nfs/rpc_pipefs
> Domain=CACTUS
> [Mapping]
> Nobody-User=nobody
> Nobody-Group=nobody
> idmapd seems to be working fine. Mappings are perfect client/server
> Here is some output, which looks OK except for the mount being read only.
>
> # mount -t nfs4:/home /mnt -o sec=krb5
> produces a lot of activity in Samba 4 including:
> Kerberos: TGS-REQ HH3$@HH3.SITE from ipv4:192.168.1.3:45825 for
> nfs/hh3.hh3.site at HH3.SITE [canonicalize, renewable]
> Kerberos: TGS-REQ authtime: 2012-01-28T21:16:16 starttime:
> 2012-01-28T21:16:16 endtime: 2012-01-29T07:16:16 renew till:
> 2012-01-29T21:16:16
>
> nd a ticket cache appears called krb5cc_machine_HH3.SITE
> and
> klist krb5cc_machine_HH3.SITE
> Ticket cache: FILE:krb5cc_machine_HH3.SITE
> Default principal: HH3$@HH3.SITE
> Valid starting Expires Service principal
> 01/28/12 18:57:25 01/29/12 04:57:25 krbtgt/HH3.SITE at HH3.SITE
> renew until 01/29/12 18:57:25
> 01/28/12 18:57:25 01/29/12 04:57:25 nfs/hh3.hh3.site at HH3.SITE
> renew until 01/29/12 18:57:25
>
> I got some rpc stuff during the mount:
> # rpc.gssd -vvvf
> beginning poll
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt13)
> handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
> handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt13)
> process_krb5_upcall: service is '<null>'
> Full hostname for 'hh3.hh3.site' is 'hh3.hh3.site'
> Full hostname for 'hh3.hh3.site' is 'hh3.hh3.site'
> Success getting keytab entry for 'HH3$@HH3.SITE'
> Successfully obtained machine credentials for principal
> 'HH3$@HH3.SITE' stored in ccache 'FILE:/tmp/krb5cc_machine_HH3.SITE'
> INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_HH3.SITE' are good
> until 1327817776
> using FILE:/tmp/krb5cc_machine_HH3.SITE as credentials cache for
> machine creds
> using environment variable to select krb5 ccache
> FILE:/tmp/krb5cc_machine_HH3.SITE
> creating context using fsuid 0 (save_uid 0)
> creating tcp client for server hh3.hh3.site
> DEBUG: port already set to 2049
> creating context with server nfs at hh3.hh3.site
> DEBUG: serialize_krb5_ctx: lucid version!
> prepare_krb5_rfc4121_buffer: protocol 1
> prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
> doing downcall
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> dir_notify_handler: sig 37 si 0xbfbd324c data 0xbfbd32cc
> destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt14
>
> user steve5 logs in:
> # su steve5
> (passwd etc...)
> Kerberos: AS-REQ steve5 at HH3.SITE from ipv4:192.168.1.3:50182 for
> krbtgt/HH3.SITE at HH3.SITE
> Kerberos: Client sent patypes: 149
> Kerberos: Looking for PKINIT pa-data -- steve5 at HH3.SITE
> Kerberos: Looking for ENC-TS pa-data -- steve5 at HH3.SITE
> Kerberos: No preauth found, returning PREAUTH-REQUIRED -- steve5 at HH3.SITE
> Kerberos: AS-REQ steve5 at HH3.SITE from ipv4:192.168.1.3:44732 for
> krbtgt/HH3.SITE at HH3.SITE
> Kerberos: Client sent patypes: encrypted-timestamp, 149
> Kerberos: Looking for PKINIT pa-data -- steve5 at HH3.SITE
> Kerberos: Looking for ENC-TS pa-data -- steve5 at HH3.SITE
> Kerberos: ENC-TS Pre-authentication succeeded -- steve5 at HH3.SITE using
> arcfour-hmac-md5
>
> steve5 goes to the share:
> # cd /mnt/CACTUS/steve5
> Kerberos: TGS-REQ steve5 at HH3.SITE from ipv4:192.168.1.3:43987 for
> nfs/hh3.hh3.site at HH3.SITE [canonicalize, renewable, forwardable]
> Kerberos: TGS-REQ authtime: 2012-01-28T21:21:50 starttime:
> 2012-01-28T21:23:29 endtime: 2012-01-29T07:21:50 renew till:
> 2012-01-29T21:21:50
>
> idmappings under the mount seem OK:
> steve5 at hh3:/mnt/CACTUS/steve5> ls -la
> total 220
> drwxr-xr-x 27 steve5 users 4096 Jan 28 21:21 .
> drwxr-xr-x 9 root root 4096 Jan 12 09:05 ..
> -rwxr-xr-x 1 steve5 users 2331 Jan 28 19:11 .bash_history
> -rwxr-xr-x 1 steve5 users 0 Jan 8 12:59 c
> drwxr-xr-x 5 steve5 users 4096 Jan 8 15:10 .cache
> drwxr-xr-x 11 steve5 users 4096 Jan 12 08:17 .config
> drwxr-xr-x 3 steve5 users 4096 Jan 8 10:31 .dbus
> drwxr-xr-x 2 steve5 users 4096 Jan 8 19:28 Desktop
> -rwxr-xr-x 1 steve5 users 23 Jan 8 10:31 .dmrc
> drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 Documents
> drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 Downloads
> -rwxr-xr-x 1 steve5 users 16 Jan 8 10:32 .esd_auth
> drwxr-xr-x 2 steve5 users 4096 Jan 9 13:41 .fontconfig
> drwxr-xr-x 3 steve5 users 4096 Jan 26 13:29 .gconf
> drwxr-xr-x 3 steve5 users 4096 Jan 8 10:31 .gnome2
> drwxr-xr-x 2 steve5 users 4096 Jan 12 09:24 .gstreamer-0.10
> -rwxr-xr-x 1 steve5 users 177 Jan 26 13:29 .gtk-bookmarks
> -rwxr-xr-x 1 steve5 users 341 Jan 9 13:42 .gtkrc-2.0
> drwxr-xr-x 2 steve5 users 4096 Jan 8 10:31 .gvfs
> -rwxr-xr-x 1 steve5 users 122 Jan 12 09:54 hello5.txt
> -rwxr-xr-x 1 steve5 users 2142 Jan 26 13:29 .ICEauthority
> -rwxr-xr-x 1 steve5 users 314 Jan 28 21:26 .joe_state
> drwxr-xr-x 3 steve5 users 4096 Jan 8 15:02 .kde4
> and:
> steve5 at hh3:/mnt/CACTUS/steve5> id
> uid=3000020(steve5) gid=100(users) groups=100(users)
> This checks OK with:
> steve5 at hh3:/mnt/CACTUS/steve5> wbinfo -i steve5
> CACTUS\steve5:*:3000020:100:steve5:/home/CACTUS/steve5:/bin/bash
> Just to be sure:
> steve5 at hh3:/mnt/CACTUS/steve5> whoami
> steve5
> _BUT_
> steve5 at hh3:/mnt/CACTUS/steve5> touch myfile.txt
> touch: cannot touch `myfile.txt': Permission denied
> So we go back to the actual home folder:
> steve5 at hh3:/mnt/CACTUS/steve5> cd /home/CACTUS/steve5
> steve5 at hh3:~> touch myfile.txt
> steve5 at hh3:~> ls -la myfile.txt
> -rw-r--r-- 1 steve5 users 0 Jan 28 21:31 myfile.txt
> And there is rw access!
>
> As the nfs4 is writeable without the krb5, that's why I thought it may
> be related to the S4 Kerbreros.
> Thanks for your patience,
> Steve
>
Unfortunately I can't be of real help here (I don't remember anything
similar from when I was using nfs4 with krb5) and it seems to be very
nfs4 specific, the kerberos (samba4) part has done its job (obtaining
machine ticket at mount time, and user ticket when you cd-ed into the
mount. What goes on from then is nfs4s own business :-( . I would
suggest to ask for help at (I don't know if there is one :-( ) a nfs4
mailing list/forum.
Good Luck!
Regards
Geza
More information about the samba
mailing list