Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1325494 - nfs mounted home cannot do graphical login
Summary: nfs mounted home cannot do graphical login
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 26
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2016-04-09 09:01 UTC by Kim Bisgaard
Modified: 2019-04-29 09:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-05-29 11:57:38 UTC
Type: Bug

Attachments (Terms of Use)
Journal from boot to graphical login (deleted)
2016-04-09 09:01 UTC, Kim Bisgaard
no flags Details

Description Kim Bisgaard 2016-04-09 09:01:29 UTC
Created attachment 1145363 [details]
Journal from boot to graphical login

Description of problem:
Cannot login to kde5 (plasma) before having done a login in virtual console. When loggin in (textual) this results in:
' -- kim: /home/kim: change directory failed: Permission denied'
cat /proc/mounts shows nfs mount as 'mounted'
and I am allowed to succeed with a 'cd'
I can still not make a successful graphical login, before executing:
'ls /home' which triggers something :-0

May be related to Bug 1323291 (

Version-Release number of selected component (if applicable):

How reproducible:

Additional info:
Machine upgraded from f23 to f24 at alpha release

Journal from boot to graphical login attached

UUID=6bfbb0ba-c87b-451e-a79a-7ca1c90e8a61 /boot   ext3    defaults        1 2
UUID=96474438-2592-433c-9d68-5f5895c4ac2b /opt    ext4    defaults        1 2
UUID=1066aafc-8288-4621-a13a-e244c277d608 /       ext4    defaults        1 1
UUID=1d7a5fad-241a-4046-b6bc-e8b88db8b882 /data   ext4    defaults        1 2
UUID=3ef6d7a8-3002-4005-8dab-c04c7eab91f5 swap    swap    defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620        0 0
jukebox:/home           /home                   nfs     defaults,comment=systemd.automount      0 0
jukebox:/data           /misc/data              nfs     defaults,comment=systemd.automount      0 0
#jukebox:/home          /home                   nfs     defaults,fscontext=unconfined_u:object_r:user_home_dir_t:s0        0 0

Comment 1 Kim Bisgaard 2016-04-09 09:30:48 UTC
Just found a selinux boolean w.r.t. nfs-home-dirs and switched it on. That's not new is it?

Does not seem to make a difference though, still same symptoms.

Comment 2 Kim Bisgaard 2016-04-10 07:10:53 UTC
I get there selinux alerts (no idea if they are related):
Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc [ dir ]
Source                        (coredump)
Source Path                   (coredump)
Port                          <Unknown>
Source RPM Packages           
Target RPM Packages           filesystem-3.2-37.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-180.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name           
Platform                      Linux
                              4.5.0-302.fc24.x86_64 #1 SMP Wed Mar 30 15:41:34
                              UTC 2016 x86_64 x86_64
Alert Count                   5
First Seen                    2016-04-02 10:52:32 CEST
Last Seen                     2016-04-10 09:00:22 CEST
Local ID                      ff65eb1c-0822-4433-966b-65df627625f4

Raw Audit Messages
type=AVC msg=audit(1460271622.820:342): avc:  denied  { mounton } for  pid=2031 comm="(coredump)" path="/etc" dev="sda3" ino=652802 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0

Additional Information:
Source Context                system_u:system_r:local_login_t:s0-s0:c0.c1023
Target Context                system_u:object_r:unlabeled_t:s0
Target Objects                / [ dir ]
Source                        login
Source Path                   login
Port                          <Unknown>
Source RPM Packages           
Target RPM Packages           filesystem-3.2-37.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-180.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name           
Platform                      Linux
                              4.5.0-302.fc24.x86_64 #1 SMP Wed Mar 30 15:41:34
                              UTC 2016 x86_64 x86_64
Alert Count                   20
First Seen                    2016-04-03 15:05:25 CEST
Last Seen                     2016-04-10 08:59:21 CEST
Local ID                      f304f308-d19a-4166-b4ec-47f58d39ff92

Raw Audit Messages
type=AVC msg=audit(1460271561.558:304): avc:  denied  { search } for  pid=1434 comm="login" name="/" dev="0:49" ino=2 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

Comment 3 Lukas Vrabec 2016-04-12 11:19:07 UTC
Yes keep boolean "use_nfs_home_dirs " turned on.
Could you run
# restorecon -R -v / 

And then try to reproduce your issue?

Comment 4 Kim Bisgaard 2016-04-13 17:33:43 UTC
Unfortunately after relabling the whole file system I still have the problem :-(

Comment 5 Kim Bisgaard 2016-05-02 08:41:44 UTC
Is is possible to give a kernel boot argument disabling selinux? - so that I can rule out that this is a selinux problem and thus a problem in (systemd/nfs/...)

Comment 6 Daniel Walsh 2016-05-02 18:15:34 UTC
enforcing=0 will disable SELinux enforcing mode
selinux=0 will disable SELinux.

Comment 7 Kim Bisgaard 2016-05-03 06:33:14 UTC
Either of these arguments, makes the problem go away - phew I got lucky to assign this close to where it belongs ;-)


Comment 8 Kim Bisgaard 2016-07-03 08:17:55 UTC
Still a problem with:

Comment 9 Kim Bisgaard 2016-09-18 08:41:08 UTC
Also in f25 with:

Comment 10 Kim Bisgaard 2016-11-16 09:08:13 UTC
Still a problem with:

Comment 11 Martin Nichol 2016-11-19 12:36:06 UTC
I have this problem too.  I also have to drop to a console and issue an ls /home to be able to login graphically.

To add a bit of information:  When I can't log in graphically and drop to the shell, the selinux label is initially unlabelled_t.  After doing nothing else but a directory listing of home, the selinux label changes to home_root_t.

I scripted the steps, and include the output here:

+ ls -Zd /home
system_u:object_r:unlabeled_t:s0 /home
+ ls /home
+ ls -Zd /home
system_u:object_r:home_root_t:s0 /home

I suspect it's more related to support for NFS attributes that was added in Fedora 24, but I don't know how to go about diagnosing the problem further.

Comment 12 Kim Bisgaard 2016-12-17 10:59:32 UTC
I had some hopes because of the other NFS bugfix but no - Still a problem with:

Comment 13 Kim Bisgaard 2017-04-14 12:41:07 UTC
Still a problem with:

Comment 14 Kim Bisgaard 2017-06-04 08:06:11 UTC
The problem disappeared this boot. Yesterday I upgraded and got:
    Upgraded   rpcbind-0.2.4-7.rc1.fc26.x86_64                   @updates-testing
    Upgrade            0.2.4-7.rc2.fc26.x86_64                   @updates-testing
    Upgraded   sssd-nfs-idmap-1.15.2-3.fc26.x86_64               @updates-testing
    Upgrade                   1.15.2-5.fc26.x86_64               @updates-testing

and others, but no selinux or systemd - go figure :-)

Comment 15 Martin Nichol 2017-06-11 10:39:27 UTC
The problem appears to have disappeared on my system too.  The last SELinux alert for that problem is from June 4th.  I did an update on that date, but installed over 400 packages which included systemd, selinux, and the aforementioned rpcbind, and sssd-nfs-idmap.  I won't be able to identify which package solved the problem.

Comment 16 Fedora End Of Life 2018-05-03 08:15:15 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 17 Fedora End Of Life 2018-05-29 11:57:38 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.