[Expired for sssd (Ubuntu) because there has been no activity for 60
days.]
** Changed in: sssd (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
** Changed in: ubuntu-release-notes
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
To manage
Groovy has now EOL'ed; we're waiting on the reporter to check whether
the issue persists on Hirsute/Impish.
** Changed in: sssd (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thanks for all the reports and letting us know about this issue.
However, there are some updates on the sssd package in Groovy since the
last comment, I do not know if they could fix this issue for you but
could you please give it a try? Also, since Groovy will become EOL soon,
could you check if
On my (upgraded from LTS) Groovy install:
systemctl status sssd.service
● sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset:
enabled)
Active: failed (Result: exit-code) since Wed 2020-12-30 01:42:46 CET; 9h
ago
Having the very same issue in 20.10 Groovy Gorilla, after updating from
20.04.1LTS to this one (getting the same error messages on boot-up and
so on.)
Inside my /etc/sssd , there is only a sub-directory /etc/sssd/conf.d/ ,
which is empty.
It seems that I can remove 'sssd' and its associated
BTW, this bug is also plaguing 20.04.1LTS users, as this was the
original thread I stumbled upon (and commented into) at first:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1889196
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Ahoy!
Another 20.10 Groovy user here who had to update from 20.04.1LTS to
20.10 because my soundcard stopped working. Well, the sound card works
now, but I get those same exact SSSD errors and I think the whole thing
was installed upon update -- at least I didn't get those errors on my
Hi,
Sorry for the delay in getting back to you.
As mentioned, adding the absolut path to my auto.DataVol1 file has fixed the
issue for me.
I think it would be preferably to add files to nsswitch.conf rather than
looking for conf entries in /etc/sssd.
For me, the only thing inside /etc/sssd is a
Hi Andreas,
I'm not using autofs, frankly, I chimed in here just to add that sssd package
had been explicitly pulled and installed during the update to groovy. And that
it failed to start for reasons unknown, too.
I didn't feel like tinkering with the problem, and given that I don't need sssd
According to the nsswitch.conf manpage, [NOTFOUND=continue] is already
an assumed default, same for "UNAVAIL" and "TRYAGAIN", so it's just a
question of whether we should add "files" to that line to cope with this
situation or not.
Alternatively, we could also add conditions to the sssd service
Andreas,
As per comment #25, I've added the absolute path to auto.DataVol1 in
/etc/auto.master as I can confirm it working.
With you comment on having:
automount: sss [NOTFOUND=continue] files
as part of /etc/nsswitch.conf, I suggest that to not break people's existing
configs, that this may be
Vladimir, from comment #15, just having sssd failing to start is not
enough for this bug. Are you also having autofs issues, and if yes, what
does your /etc/auto.master look like? Do you also have a map file
without a full path?
--
You received this bug notification because you are a member of
I understand sssd is failing to start because there is no config, but
I'm trying to understand the bad interaction of automounts with sssd,
which would be via /etc/nsswitch.conf.
(Brainstorming below, pardon me if this is all obvious to you)
autofs will consult /etc/nsswitch.conf when a map file
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
Hi,
Well this explains why this is starting to happen:
https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/390221
They're adding Active Directory to the new user creation in the
installer.
There's also a design doc that explicitly mentions SSSD:
The sudo delay is likely due to dns, I see that in other boxes and
ubuntu releases too. But let's see.
** Changed in: sssd (Ubuntu)
Importance: Low => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Same here aas in comment #15. I didn't have SSSD installed prior to the
upgrade and it was "ubuntu-desktop-minimal" that pulled SSSD in. Not
only did it break my automount but also login and sudo would take about
a 4 seconds delay to succeed - as I guess it was trying to auth via SSS.
Grepped
And it's libnss-sss that adds "automount: sss" to nsswitch.conf
Does it work if you comment that out? This is yet another case of not
having an 'update-nsswitch' tool to add entries when needed, the current
packaging assumes that installing sssd means it's also configured..
--
You received this
ubuntu-desktop Recommends: sssd, that's what's pulling it in.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
To manage
Could you please attach them? I'd like to know what pulled sssd in
On Tue, Sep 29, 2020, 23:55 Vladimir Yerilov <1897...@bugs.launchpad.net>
wrote:
> Hi, I had no intention to use sssd, it was pulled and installed during the
> update. I am sure I had no sssd installed on focal as I am browsing
Hi, I had no intention to use sssd, it was pulled and installed during the
update. I am sure I had no sssd installed on focal as I am browsing now through
the image of my root partition created before the update was started.
Yes, I still have update logs.
--
You received this bug notification
Do you still have the upgrade logs from focal to groovy?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
To manage notifications
Hi @openmindead, what is your goal with sssd? Or you didn't have it
installed in focal, and it got installed after upgrading to groovy?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
This bug "affects" me too. In a way that sssd fails to start. Also any attempt
to run something like "systemctl enable foo.service" is now being rejected
after entering correct password in pkexec popup window, so I have to use "sudo
systemctl enable foo.service". Log show sssd.service and its
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: sssd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
I wouldn't suggest that SSSD has anything done particularly for AutoFS
but I would make a case for the package maintainers having a default
/etc/sssd config file(s) that if nothing else has options
commented/hashed out and ready ti be uncommented and used. This would
be much like how *insert your
We could also investigate if there is something to be done regarding the
interaction of an unconfigured sssd and an existing autofs setup. But if
we proceed here on that basis then I don't think this needs priority and
so it probably won't get looked at. If you learn anything new that makes
this
oh it's known that the desktop metapackage(s) depend on it now
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
To manage
Understood.
I guess the last thing I can do here is take the 20.04 VM I've made and
upgrade it to Groovy to see if SSSD is installed as a dependancy of
something else.
I'll do that over the next day or two.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Right, I was going to say it looked like your setup wasn't using sssd,
hence my question about /etc/nsswitch.conf.
sssd needs to be configured after installation, at most it adds "sss" to
/etc/nsswitch.conf, but the actual sssd.conf needs to be populated by
hand, or by another tool such as realm
After doing a fresh install of 20.04 in a VM and then installing autofs, I've
concluded that SSSD isn't needed for my setup.
This does leave the question why SSSD was installed and if it was installed
upon upgrade to Groovy.
Either way, it seems that when SSSD is installed (either on 20.04 or
I installed 20.04 fresh in a Gnome Boxes VM and installed autofs (sudo apt-get
install autofs).
SSSD was not installed as a dependancy.
Then, I installed SSSD (sudo apt-get install sssd) just to see what
/etc/sssd looked like and it's actually the same. there's no config file
under /etc/sssd and
Nope, there's no files under /etc/sssd and I didn't touch this directory
when upgrading to the Groovy daily image. When I have a moment, I'll
install 20.04 in a VM for a comparison of what should be in /etc/sssd
But as far as /etc/nsswitch.conf goes:
# /etc/nsswitch.conf
#
# Example
You don't have /etc/sssd/sssd.conf? Do you have "sss" entries in
/etc/nsswitch.conf?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153
Title:
Automount fails due to SSSD config (Groovy Gorilla)
I never looked at SSD closely prior to upgrading from 20.04 to 20.10 so I don't
know what was there before as it 'just worked'.
Presently though, the only thing under /etc/sssd is an empty conf.d
(/etc/sssd/conf.d) directory.
I did reinstall the SSSD packages after upgrade to 20.10 however the
Are you using a "services=" line in /etc/sssd/sssd.conf, to have sssd
itself start services? It might be conflicting with the individual
systemd services that are trying to start. Not saying it's the cause of
your problem, but might be the cause of some log noise that is getting
in the way of
Trying to restart SSSD give the following errors with journlctl -xe:
The job identifier is 11972 and the job result is failed.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD Sudo Service
responder socket.
░░ Subject: A start job for unit sssd-sudo.socket has failed
░░ Defined-By:
Additional points:
* Able to always reproduce
* Able to manually mount volumes (doing so as temp workaround)
dpkg -l sssd
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err:
39 matches
Mail list logo
