[Freeipa-users] Problem automounting home shares

[Ronald Wimmer]

Hi,

I am trying to automount user home shares from an NFS server. Up to now,
without success.

Some details regarding my setup: I have a CentOS 7.3 machine acting as
an NFS server. It is a host within my IPA domain and enrolled as an IPA
client.

[***@ipanfs ~]# cat /etc/exports

/homeshare *(rw,sec=krb5:krb5i:krb5p)


I followed this guide
https://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/

I defined a automount location called ipauserhome. In this location I
have a map called auto.home with this content:

* -fstype=nfs4,rw,sec=krb5 ipanfs.linux.oebb.at:/homeshare/&

On an ipa client I just did "ipa-client-automount
--location=ipauserhome" and "authconfig --enablemkhomedir --update".

When I login on the ipa client I get the error message "Could not chdir
to home directory [...] No such file or directory.".

I see that home is mounted on the client

auto.home on /home type autofs
(rw,relatime,fd=12,pgrp=1079,timeout=300,minproto=5,maxproto=5,indirect)

[***@testclient ~]# ls -alh /home

total 4,0K

drwxr-xr-x. 2 root root 0 12. Apr 10:22 .

dr-xr-xr-x. 17 root root 4,0K 11. Apr 17:52 ..


but for some reason it works not as expected. SELinux is set to
permissive on both NFS server and the ipa client. Nevertheless, I get a
suspicious message in /var/log/messages:

Apr 12 10:22:48 testclient dbus[804]: [system] Successfully activated
service 'org.fedoraproject.Setroubleshootd'

Apr 12 10:22:48 testclient dbus-daemon: dbus[804]: [system] Successfully
activated service 'org.fedoraproject.Setroubleshootd'

Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory /. For
complete SELinux messages. run sealert -l
76dd44bd-9ba6-4bf3-ba75-72834533cb0e

Apr 12 10:22:49 testclient python: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory
/.#012#012***** Plugin catchall (100. confidence) suggests
**************************#012#012If you believe that mkhomedir should
be allowed write access on the directory by default.#012Then you should
report this as a bug.#012You can generate a local policy module to allow
this access.#012Do#012allow this access for now by executing:#012#
ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012#
semodule -i my-mkhomedir.pp#012

Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory /. For
complete SELinux messages. run sealert -l
76dd44bd-9ba6-4bf3-ba75-72834533cb0e

Apr 12 10:22:49 testclient python: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory
/.#012#012***** Plugin catchall (100. confidence) suggests
**************************#012#012If you believe that mkhomedir should
be allowed write access on the directory by default.#012Then you should
report this as a bug.#012You can generate a local policy module to allow
this access.#012Do#012allow this access for now by executing:#012#
ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012#
semodule -i my-mkhomedir.pp#012

Apr 12 10:22:49 testclient setroubleshoot: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory /. For
complete SELinux messages. run sealert -l
76dd44bd-9ba6-4bf3-ba75-72834533cb0e

Apr 12 10:22:49 testclient python: SELinux is preventing
/usr/libexec/oddjob/mkhomedir from write access on the directory
/.#012#012***** Plugin catchall (100. confidence) suggests
**************************#012#012If you believe that mkhomedir should
be allowed write access on the directory by default.#012Then you should
report this as a bug.#012You can generate a local policy module to allow
this access.#012Do#012allow this access for now by executing:#012#
ausearch -c 'mkhomedir' --raw | audit2allow -M my-mkhomedir#012#
semodule -i my-mkhomedir.pp#012

Apr 12 10:23:51 testclient automount[1079]: st_expire: state 1 path /home

Apr 12 10:23:51 testclient automount[1079]: expire_proc: exp_proc =
139761696524032 path /home

Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: got thid
139761696524032 path /home stat 0

Apr 12 10:23:51 testclient automount[1079]: expire_cleanup: sigchld: exp
139761696524032 finished, switching from 2 to 1

Apr 12 10:23:51 testclient automount[1079]: st_ready: st_ready(): state
= 2 path /home

Apr 12 10:25:06 testclient automount[1079]: st_expire: state 1 path /home

Where to look next?

Regards,
Ronald

[Ronald Wimmer]

[...]
You cannot use indirect mounting and enablemkhomedir at the same time. Indirect mounts require that the directory you are attempting to mount already exists on the NFS server and that you let autofs fully manage the "parent" directory on the client machine. In this case, no one other than autofs can create directories in the top-level of /home on your clients (/home/<user> is a different story).
So you either need to pre-create the home directories on your NFS server (including ownership, permissions, and any "skel" stuff you want in there like a default .bashrc) or you need to direct mount /home altogether and lose the benefits of indirect mounting (which may not matter to you).
[...]

So this means I can either use /home mounted as NFS share conventionally
(without autofs) in combination with mkhomedir or use autofs magic with
pre-created directories.

As my users come from AD I do not even know which directories would have
to be created in advance. So I will have to go for option 1.

[Jason B. Nance]

Post by Ronald Wimmer

You cannot use indirect mounting and enablemkhomedir at the same time. Indirect
mounts require that the directory you are attempting to mount already exists on
the NFS server and that you let autofs fully manage the "parent" directory on
the client machine. In this case, no one other than autofs can create
directories in the top-level of /home on your clients (/home/<user> is a
different story).
So you either need to pre-create the home directories on your NFS server
(including ownership, permissions, and any "skel" stuff you want in there like
a default .bashrc) or you need to direct mount /home altogether and lose the
benefits of indirect mounting (which may not matter to you).
[...]

So this means I can either use /home mounted as NFS share conventionally
(without autofs) in combination with mkhomedir or use autofs magic with
pre-created directories.

You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/<username>" individually.

Regards,

j

[Ronald Wimmer]

Post by Jason B. Nance
[...]
You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/<username>" individually.

Thanks for clarification. I made a direct map for /home now that looks like:
/home -fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare

If i try to login on my testclient, the user home directory gets
created. Permissions (UID/GID) are set correctly but the directory is
still inaccessible for the user.

My question is why? Is it because i set sec to sys here? When I set it
to krb5, automount does not even mount /home

[Ronald Wimmer]

Post by Ronald Wimmer

Post by Jason B. Nance
[...]
You can still use autofs and mkhomdir, just use a direct mount for
/home instead of indirect mounts. In other words, mount "/home"
entirely vs. "/home/<username>" individually.

/home -fstype=nfs4,rw,sec=sys ipanfs.mydomain.at:/homeshare
If i try to login on my testclient, the user home directory gets
created. Permissions (UID/GID) are set correctly but the directory is
still inaccessible for the user.
My question is why? Is it because i set sec to sys here? When I set it
to krb5, automount does not even mount /home

It was my own fault. I somehow messed up the /etc/krb5.keytab on the
testclient. After correcting it everything works like a charm.

Regards,
Ronald

[Ronald Wimmer]

Post by Ronald Wimmer
[...]
It was my own fault. I somehow messed up the /etc/krb5.keytab on the
testclient. After correcting it everything works like a charm.

No. It was not....I was mistaken. The problem is:

- sec=sys
when I set sec=sys, the share gets automounted and the directory gets
created
with the right permissions but the user gets a "Permission denied"
fore some reason
- sec=krb5
the share does not even get automounted

sec=krb5p:
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
looking up /home
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
/home -> -fstype=nfs4,rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
expanded entry: -fstype=nfs4,rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
gathered options: fstype=nfs4,rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
dequote("ipanfs.linux.mydomain.at:/homeshare") ->
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
core of entry: options=fstype=nfs4,rw,sec=krb5p,
loc=ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: sun_mount: parse(sun):
mounting root /home, mountpoint /home, what
ipanfs.linux.mydomain.at:/homeshare, fstype nfs4, options rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
root=/home name=/home what=ipanfs.linux.mydomain.at:/homeshare,
fstype=nfs4, options=rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
nfs options="rw,sec=krb5p", nobind=0, nosymlink=0, ro=0
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: called with
host ipanfs.linux.mydomain.at(10.66.39.164) proto 6 version 0x40
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: nfs v4 rpc
ping time: 0.000265
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: host
ipanfs.linux.mydomain.at cost 265 weight 0
Apr 14 13:30:06 testclient automount[17792]: prune_host_list: selected
subset of hosts that support NFS4 over TCP
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mkdir_path /home
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mount -t nfs4 -s -o rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare /home
Apr 14 13:30:06 testclient automount[17792]: spawn_mount: mtab link
detected, passing -n to mount
Apr 14 13:30:06 testclient gssproxy: gssproxy[889]: (OID: { 1 2 840
113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more
information, No credentials cache found
Apr 14 13:30:06 testclient automount[17792]: >> mount.nfs4: access
denied by server while mounting ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: mount(nfs): nfs: mount
failure ipanfs.linux.mydomain.at:/homeshare on /home
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 55
Apr 14 13:30:06 testclient automount[17792]: failed to mount /home
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 56, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 56
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 57, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 57

I would like to start with sec=sys - why doest the user get a permission
denied even if its home directory appears to have the right permissions?
Where do I have to look into?

Regards,
Ronald Wimmer

[Ronald Wimmer]

I got a little further. Now the share also automounts on the client with
sec set to krb5 but the user still gets a "Permission denied" and cannot
access his home directory. Can it be related to the fact that the user
comes from AD? (Unfortunately, I cannot test with a native IPA user due
to another issue.)

[Ronald Wimmer]

Here are my findings. The problem seems to be related to mkhomedir. By
default my homedir looks like /home/%d/%u. In this case, when a user
logs in for the first time /home/%d gets created and the %u part is
missing. If I create it manually everything works fine.

If i set override_homedir to /home/%u in the testclients sssd (nss
section) settings the directory gets created and almost everything works
fine. On the first login I get a "Could not chdir to home directory
/home/myuser: No such file or directory" - the directory seems to get
created to late.