Type of issue

Other (issue in content formatting, broken link or image, non-working widget)

Problem description

In the blog, a tooltip is used to render terminology explanations when content is viewed directly in a browser. But feed readers traditionally don’t support styles, and so the content is broken up by the <span class='terminology-tooltip'> elements’ content being shown mid-sentence. For instance, this paragraph in the 2026.11 release post

<p>Targets are a great way to keep your <span class='terminology'>automations<span class='terminology-tooltip'>Automations in Home Assistant allow you to automatically respond to things that happen in and around your home.<a class='terminology-link' href='/docs/automation/'> [Learn more]</a></span></span> and <span class='terminology'>scripts<span class='terminology-tooltip'>A script is a saved list of steps that runs when you start it, for example, from a dashboard, with Assist, or from an automation. Unlike an automation, a script has no triggers, so it doesn’t start by itself.<a class='terminology-link' href='/docs/script/'> [Learn more]</a></span></span> up to date. Point one at an <span class='terminology'>area<span class='terminology-tooltip'>An area in Home Assistant is a <a href="/docs/organizing/">logical grouping</a> of devices and entities that represents a room or space in your home, such as the living room, kitchen, or garage.<a class='terminology-link' href='/docs/organizing/areas/'> [Learn more]</a></span></span>, a <span class='terminology'>floor<span class='terminology-tooltip'>A floor in Home Assistant is a <a href="/docs/organizing/">logical grouping</a> of areas that are meant to match the physical floors in your home...

is basically unreadable in my feed reader (Tiny Tiny RSS):

Suggested solution

IDK what CMS the blog runs on, but it needs to render those terminology explanations in the feed in a way that doesn’t break the content, or not at all.

URL

https://www.home-assistant.io/atom.xml

Version

2026.11.0

How do you know the suggested solution is correct?

No response

Additional information

I’m re-reporting this; I posted #35042 two years ago, but it went ignored, and this is still an issue.

Kiitokset englanninkielisistä tekstityksistä. Näin suomea äidinkielenään puhuvanakin arvostan, kun saa tuplasti huumoria samalla rahalla! Ja ovathan nuo myös hyödyllisiä silloin, kun korvakuulolta menee jotain ohi.

My laptop (a Dell Latitude 5400, running Ubuntu 26.04) is also affected by this. /usr/libexec/geoclue-2.0/demos/where-am-i is able to get my location, yet go-hass-agent always reports the same error it does for OP:

1:17PM DEBUG Location updated.
1:17PM DEBUG Invalid sensor data. error="contains field errors\ninvalid field Name (value(\"\")) failed validation for required: Key: 'Sensor.Name' Error:Field validation for 'Name' failed on the 'required' tag\ninvalid field State (value(\"<nil>\")) failed validation for required: Key: 'Sensor.State' Error:Field validation for 'State' failed on the 'required' tag\ninvalid field Type (value(\"\")) failed validation for required: Key: 'Sensor.Type' Error:Field validation for 'Type' failed on the 'required' tag\ninvalid field UniqueID (value(\"\")) failed validation for required: Key: 'Sensor.UniqueID' Error:Field validation for 'UniqueID' failed on the 'required' tag

The device tracker’s state in HA remains ”Unknown”.

Steps to reproduce:

1. use update manager to install updates that require a restart
2. after installing the updates, update manager asks whether to restart now or later: select restart now
3. realize you have unsaved work, so from the additional restart confirmation dialog that pops up, select ”cancel”

What I expect to happen
For the restart to get cancelled

What happens instead
A restart; there goes your unsaved work

Further info
I can’t remember if I’ve tried to approve the restart from that final dialog instead of cancelling it, so I don’t know if that would cause the restart to go ahead too (which would be expected), or if the buttons have their labels switched.

I’ve had this happen twice since upgrading from 24.04 to 26.04. To be clear, the symptoms were as described by Mihail in comment #12 above (and not whatever the OP reported):

loka 25 17:39:30 saegusa systemd[1]: Starting user@60579.service – User Manager for UID 60579…
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed to determine credentials for user ’60579’: Unknown user
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed at step USER spawning /usr/lib/systemd/systemd: Invalid argument
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Main process exited, code=exited, status=217/USER
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Failed with result ’exit-code’.
loka 25 17:39:30 saegusa systemd[1]: Failed to start user@60579.service – User Manager for UID 60579.
loka 25 17:39:30 saegusa systemd[1]: Started session-c1.scope – Session c1 of User gdm-greeter.
loka 25 17:39:30 saegusa systemd[1]: Started apache2.service – The Apache HTTP Server.
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus[2491]: Unable to set up transient service directory: XDG_RUNTIME_DIR ”/run/user/60579” is owned by uid 60579, not our uid 60578
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus-daemon[2491]: [session uid=60578 pid=2491 pidfd=5] Cannot set up inotify for ’/run/gdm3/home/gdm-greeter/.local/share/dbus-1/services’: Permission denied

The first time it happened during a normal reboot, and resolved itself after I rebooted again (using ssh to log in from another system). The second time (last night, as logged above) it happened after a reboot due to VLC causing an unrelated Xwayland crash, and no amount of rebooting ever fixed it.

I stopped nscd (`systemctl stop nscd; nscd -i passwd; nscd -i group`), after which restarting GDM (`systemctl restart gdm`) finally brought the login screen back. I then disabled nscd (`systemctl disable nscd`) to make sure it won’t mess things up again on the next reboot.

The suggestion to stop nscd came from ChatGPT, which apparently based it on a reply to an Ask Ubuntu thread about the same issue [1]. I don’t know what unwanted consequences disabling nscd potentially has, but at least I have a working desktop for now.

* [1] https://askubuntu.com/a/1570171

Here’s how Arch fixed it:

[Service]
ProtectHome=read-only
PrivateDevices=no
DeviceAllow=/dev/urandom r
DeviceAllow=char-hidraw rw

According to a comment on the related polkit report ”That’s the correct way to solve these issues”.

Mattermost Server Version

11.10.2

Operating System

Ubuntu 26.04 (and probably any other Unix-like OS)

Steps to reproduce

1. wget https://releases.mattermost.com/11.11.0/mattermost-11.11.0-linux-amd64.tar.gz # current latest
2. tar tvf mattermost-11.11.0-linux-amd64.tar.gz | head

Expected behavior

drwxrwxr-x root/root         0 2026-09-11 08:52 mattermost/
drwxrwxr-x root/root         0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-r-- root/root  32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root  15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root  16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root   9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig

Observed behavior

drwxrwxrwx root/root         0 2026-09-11 08:52 mattermost/
drwxrwxrwx root/root         0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-rw- root/root  32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root  15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root  16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root   9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root       566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig

Additional Information

The installation instructions suggest extracting the files as non-root, which will result in the user’s umask being applied to the output files, so that’ll cause the world-writablity bit to get dropped (hopefully for most users).

It’d still be better though if the files were 0660/0770 (or at least 0664/0775) even when extracted as root. (Group-writability is enforced by the instructions’ sudo chmod -R g+w /opt/mattermost in any case.)

⚠️ Before submitting, please verify the following: ⚠️

• ☑ This is a bug, not a question or a configuration issue.
• ☑ This issue is not already reported on Github (I have searched for it).
• ☑ Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• ☑ I agree to follow Nextcloud’s Code of Conduct

Bug description

Selecting ”Add account” from the tray icon menu crashes the client.

Steps to reproduce

1. Click on the tray icon
2. Select Add account

Expected behavior

Account creation wizard appears.

Which files are affected by this bug

I don’t understand this question.

Operating system

Linux

Which version of the operating system you are running.

Ubuntu 24.04

Installation method

Community PPA (please test with the AppImage package ?)

Nextcloud Server version

34.0.3.2

Nextcloud Desktop Client version

34.0.2-20260819.104017.ea499374cb-1.0~noble1

Did this occur after an update or on a clean installation?

Minor version update (i.e. 33.0.0 → 33.0.1)

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• ☑Default internal user-backend
• ☐ LDAP or Active Directory
• ☐ SSO – SAML
• ☐ Other

Nextcloud Server logs

Additional info

I tried the Appimage and it doesn’t seem to be affected (i.e. it doesn’t crash, and the account creation wizard appears).

I lied in answering ”Did this occur after an update or on a clean installation?” question above, because it’s been years since I’ve last tried adding accounts to the client and don’t really know the answer, but the choices given don’t account for this possibility.

”Debug archive creation is not available on this platform.” But I created a log according to the instructions in #10535’s comments and am attaching it here.

crash.log

I just built 2.42.3, and it appears to have fixed this — maybe via [PR #9789](https://github.com/mattermost/mattermost-mobile/pull/9789#:~:text=bad%2Dcertificate%20reporting.-,Build%20Script,-File%3A%20scripts)?

Nevermind, this happened multiple times again today. Guess I just had a lucky streak of a couple of weeks there when it didn’t.