Gnome in F37 shows no applications, no results in searchbox | via nis/pam login

Running latest gnome displays no applications, If searching for anything in search bar - no results.

If running as local user i.e root, or create new local user - it works.
When running as user logged in via nis/pam with nfs mounted /home - does not work.

Fresh install of F37, or upgrade from F36 makes no difference.
Tried purging all form of .cache .ccache .local/shared .config related directories, makes no difference.

Other window managers work without issues, for instance Cinnamon/Gnome Classic.

Have anyone seen issues like this? Currently our work around is to simply switch to another WM, which works but isn’t ideal.
Would love to get a better understanding of why this isn’t working after F37 for us, and hopefully some pointers in where to troubleshoot.

Regards,

Hello Staffan,
Have you any clues on this ? I have exactly the same problem and have not been able to find a solution for it. Thanks in advance

Hey Paulo,

Firstly I’d just like to say that it’s nice to hear at least someone else is having the same kind of issues. But unfortunately I’m still stuck on the same spot with this. As you can see, no help whatsoever has been available in this thread.

Do you happen to have any findings on your end to share in what might be the cause?

Thanks.

1 Like

I was reading here in other topics that Gnome just indexes the /home folder (localy). This might explains why it not works. As described above you not fulfill the cri-terias as an locally user.
I also could imagine that PAM needs to be configured for that:

https://www.redhat.com/sysadmin/pluggable-authentication-modules-pam

Changed the title to attract more users

2 Likes

Something must have changed in gnome because on previous versions this would work out of the box. Is gnome not indexing folders that reside on a NFS ? I am a bit lost on what could I do to change this behavior. I also find it strange that no applications are found as those do not reside in the NFS partition. As those are local they should appear. I can not even add favorites in gnome-shell. So the system is basically useless as it is… There is no information on the system logs concerning gnome-shell. I am going to give it a go this afternoon but I do not have a lot of things to test further…

As I mentioned as nis/pam user you are not seen as a local user and so you not have the rights to browse. Over fling the article above, I saw that you have config files for pam. It says something about checking the shadow file etc.

Probably a good idea would be, also to post on “Gnome Forum”. Must be more gnome related ?!

2 Likes

Thank you for your input, however, this has never been an issue before as we’ve been running nfs-mounted /home for years and years. That pam or gnome all of a sudden would start indexing /home and differ it as if it was local stored or not seems very odd.
Running Gnome Classic and every other kind of WM works.
And also as Paulo said, applications are not stored in /home as they reside in the OS-install path like /usr /opt and such.

What I’ve come to conclude is that something is changed with how gnome or fedora 37 (or the two combined) allows the auth:ed user to read .cache/.local/etc files and thus failing this - nothing is displayed.

I will check out the article you posted and see what can be found in there, thank you.

I just repeat what I was reading here (https://discussion.fedoraproject.org/t/files-app-does-not-use-tracker3-created-index-outside-home/74035).
That’s why I proposed also to see at Gnomes Forum.

Apropos, I do have a .cache in my home directory … and there are files cached from Zoom etc.

2 Likes

Does this mean the failure is when using the default ‘gnome’ on wayland but it works when using ‘gnome-classic’ on wayland? Or is it also failing when using ‘gnome on xorg’ and working when using ‘gnome-classic on xorg’

The term “every other kind of WM” is quite open to readers interpretation and not at all definitive for what may have been tried.

1 Like

We disable wayland by default at time of first boot since there’s been loads and loads of issues with it. So we’re running Xorg, and to clarify “gnome classic” is simply called “gnome classic on xorg” in menu selection, it’s basically gnome without the fancy gui.

So all other WM’s I’ve tried (mate, kde, cinnamon, xfce, blackbox) all run on Xorg.

My point with that other WM’s work fine, is that most/many of them use gnomes backend, which makes it weird that gnome ‘standard’ itself does not work.

1 Like

I have exactly the same experience on a similar system. Wayland is disabled and X11 is used (we use a lot of programs that have had issues with wayland). The other Desktop Environments I have tested are “gnome classic on xorg” and “cinnamon” and both work as expected: the applications menu is populated and it works.

In a desperate attempt to find if the problem was not from upgrading, I installed one computer node with fedora 37 after wiping the system. I can login remotely with ssh to the new node using a NIS user and everything seems to work, but when I try to login using the NIS user (I am using gdm and gnome) the system seems to accept my password but it immediately returns to the login manager screen. I do not know this is related to the problem being reported, but for me it seems something funny is going on with NIS on fedora 37. If I have the time I will try to install an openldap server and see if the problem persists. I am resisting doing this because ldap is much more troublesome to use and configure than NIS. Adding users is such a chore on ldap, but if this works I will make the transition. Thanks everyone who has taken the time to look at this.

This I saw here several times reported. So it can have different causes. If you said NIS worked before you might have to check in the web generally.

Here an example:
https://discussion.fedoraproject.org/t/login-loop-on-gnome-login-fedora-35/67147

If I can login remotely I would assume that loging through gdm would also work. For me it is strange that one works and the other does not. I configured NIS on the newly installed computer as I always do …
There is something really broken with NIS in fedora 37 and I can not find the cause for it. I have no messages in the logs that can help me even diagnose the problem. As I said the system recognizes the password both in gdm and ssh. Even logging through the console works. The report you point to does nothing to me and it is not related in any way to my problems. The system is freshly installed.

You could change to lightdm and login this way.
Then you debug the bootlog with:

sudo sed $'s/\^\[/\E/g' /var/log/boot.log

That is what you get when you press ESC while booting to see the messages. I’m sure it will give you a hint before or after the gdm.

The issues you describe I’m not familiar with as actual login has never been the problem for me. However we did see similar issues after latest kernels in F36, the solutions for me was to switch over to lightdm instead of gdm, but in our case - gdm would crash x11 on boot so…

Note that we use pam as well and had to relink lightdm conf to system-auth for logins to work etc.

Staffan,
I solved all my problems by replacing NIS/YP with OpenLDAP. Now everything works in gnome, the applications list is correctly populated and I have no other issues with the system. Granted, it is not as easy to install/configure or even add user as NIS is, but I think it is worth it in the long run. If I am reading this correctly ( Changes/drop NIS support from PAM - Fedora Project Wiki ) NIS will be dropped starting with Fedora 38.
Thanks

I took a stab at this and found that the accounts-daemon when loaded from systemd is running with restricted network access.
Changing PrivateNetwork=true to false, commenting out RestrictAddressFamilies=AF_UNIX and then restarting accounts-daemon.service solved this issue for me.

2 Likes

Thanks Mattias for giving it a go. Now that I have made the change to openldap and with nis being discontinued, I dont think I am going back to NIS. But I am really glad you found the solution!