- keyboard
- ibus error
- I dont think so
That’s not enough information for me to offer any suggestions.
So there’s nothing in the dmesg output mentioning ibus? Does journalctl -xe -g ibus show anything?
I’ve the same problem here, but in Ubuntu 22.04.3 LTS. I used the snap version of Firefox for quite some time, but suddenly it stopped working. I discovered that, as in this case, the issue was with the uncommon home location (my home is something like /home/domain/user, pretty common in AD administered network).
The issue with homes not directly under /home seemed to be solved in new snap version; indeed after upgrading snap (snap refresh --channel=latest/edge snapd) Firefox worked again.
Until now, apparently for no reasons. I can start Firefox and other snap packages, but keyboard input doesn’t work. When I start Firefox I see:
WARNING: Unable to connect to ibus: Impossibile connettersi: Permission denied
and in journal:
set 29 14:45:50 Ubuntu20 firefox[166094]: Unable to connect to ibus: Impossibile connettersi: Permission denied
set 29 14:45:50 Ubuntu20 firefox_firefox.desktop[166094]: [Parent 166094, Main Thread] WARNING: Unable to connect to ibus: Impossibile connettersi: Permission denied: ‘glib warning’, file /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167
set 29 15:00:13 Ubuntu20 dbus-daemon[4565]: apparmor=“DENIED” operation=“dbus_method_call” bus=“session” path="/org/freedesktop/IBus" interface=“org.freedesktop.DBus.Peer” member=“Ping” mask=“send” name=“org.freedesktop.portal.IBus” pid=182284 label=“snap.firefox.firefox” peer_pid=5826 peer_label=“unconfined”
I tried rebooting, upgrading snap again, using IBUS_USE_PORTAL=1, but without success.
Keyboard input stopped working for all my snaps too after a recent upgrade. User accounts are from a domain controller, and homefolders in /home/domain/$user. Finally got it running again after using this in /var/lib/snapd/apparmor/profiles and a reboot:
sed -i 's:peer=(addr="@/home/\*/.cache/ibus/dbus-\*"),:peer=(addr="@/home/domain/\*/.cache/ibus/dbus-\*"),:g' *
Is it possible with a permanent fix and make it work with both local and domain users? I can help debug, but have very limited knowledge about this.
This did not help for me.
If I, for some, very, very strange reaons could need a keyboard in firefox, i gotta edit the /var/lib/snapd/apparmor/profiles/snap.firefox.firefox file by replace 2 sections
#unix (connect, receive, send)
# type=stream
# peer=(addr="@@{HOME}/.cache/ibus/dbus-*"),
unix (connect, receive, send)
type=stream
peer=(addr="@/home/*/.cache/ibus/dbus-*"),
with
# abstract path in ibus >= 1.5.22 uses $XDG_CACHE_HOME (ie, @{HOME}/.cache)
# This should use this, but due to LP: #1856738 we cannot
unix (connect, receive, send)
type=stream
peer=(addr="@@{HOME}/.cache/ibus/dbus-*"),
#unix (connect, receive, send)
# type=stream
# peer=(addr="@/home/*/.cache/ibus/dbus-*"),
Well… after doing so, I will still have an AppArmor parser error, forcing me to locate this section in same file (almost at end of the file):
# allow use of user namespaces
userns,
and replace this with
# allow use of user namespaces
userns r,
After doing so, I can finally do a apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.firefox.firefox and then ask my self… why the **** did ubuntu replace the apt-package for firefox whit this stupied sh*t that doesn’t support custom “domain”-homedirs such as /home/domain/$user$
If I accidently either turn of the computer or reboot it, I gotta do the apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.firefox.firefox part again in order to be able to even launch firefox…
And when the thing updates? Well, then I gotta start from scratch and do the editing and then run the parser…
Yes, i know we can do PPA (ppa:mozillateam/ppa) to get back the working firefox again, but I really wonder howcome this takes several months to fix officailly.
I am also having this problem. It occurs with evince.
I see the errors shown in the terminal window: The first error
(evince:24091): IBUS-WARNING **: 10:34:35.496: Unable to connect to ibus: Could not connect: Permission denied
occurs immediately when evince runs and the second error:
(evince:24091): GLib-WARNING **: 10:35:14.672: getpwuid_r(): failed due to unknown user id (1855985172)
occurs when I try to add a note to a PDF document and type something. The note does not accept keyboard input.
@Nope I’ve been messing around with this same issue. It turns out the files in /var/lib/snapd/apparmor/profiles are read by a different apparmor service than the ones in /etc/apparmor.d and for some reason have different requirements for the files.
There is apparmor.service which is what using apparmor_parser references and reads /etc/apparmor.d by default then there is snapd.apparmor.service which reads the files in /var/lib/snapd/apparmor/profiles
using apparmor_parser -r doesn’t like “userns,” and works when replacing it with “userns r,”. However, snapd.apparmor.service fails to start with a parser error with “userns r,”
This is why @bmbob was able to just edit the peer=… line and ignore the userns, line when he rebooted but yours (and mine) failed when trying to do the same with apparmour_parser -r. I’m now using systemctl restart snapd.apparmor.service if I edit the files in /var/lib/snapd/apparmor/profiles/
I suspect future updates may rewrite these file modifications so I’m looking for a way to guarantee their permanence. If anyone has specific knowledge on this point I would be grateful. I’d also be interested in the rational for separate apparmor service for snaps as well as different parsing requirements for userns. I’m sure there is a good reason but the problem with “non-standard” though in my mind “very acceptable and normal alternative” homedirs makes me want to run away from snaps.