"Failed to parse config" when config is in symlinked directory

[buster]

I'm linking my dotfiles from another directory and mako doesn't seem to work with symlinked config files:

~/.config
❯ pwd
/home/buster/.config

~/.config
❯ cat mako/config
layer=overlay
anchor=top-left

~/.config
❯ mako
^C
~/.config took 2s
❯ echo "mako runs.."
mako runs..

~/.config
❯ rm -rf mako/

~/.config
❯ ln -s ~/Sync/dotfiles/misc/.config/mako

~/.config
❯ cat mako/config
layer=overlay
anchor=top-left

~/.config
❯ ls -la mako
lrwxrwxrwx 1 buster buster 44 22. Aug 17:35 mako -> /home/buster/Sync/dotfiles/misc/.config/mako

~/.config
❯ mako
Unable to open /home/buster/.config/mako/config for readingFailed to parse config

[vilhalmer]

I'm not sure what's going on here, I use the same setup and it's able to read the file. Does the same file work if you pass the real path with -c?

[buster]

One thing i didn't try, was to use the file in the original directory itself (which is not a symlink), and that doesn't work either.
I tried with strace and i don't understand why it saying "no permission":
Also, strace shows some calls to use SELINUX, which i don't have or use (Debian):

So i'd say it doesnt have to do with symlinks but i still don't understand what is going on, because i am just copying this file to ~/.config/mako/config as is, and mako works..

Also, i'm using a lot of symlinked dotfiles on my system and this never happened on other programs.

[ReadWriteError]

I have a temporary solution for anyone still having problems with this and it's really weird. Just copy or even hard link (but not symbolic) /usr/bin/mako into /usr/local/bin/. That's it. Well you also may have to adjust systemd or any scripts to use /usr/local/bin/makoif they have a full path. I documented more strange behavior and related problems in #392.

[vilhalmer]

Sorry for the long delay. This feels like apparmor, do you have it enabled? Maybe it treats a symlink there as not allowed even though we have a whitelist for that path as a normal file?

[op]

I ran into this problem. I generate ~/.cache/mako/config depending on light/dark mode. ~/.config/mako/config is then linked to this file. This worked fabulous as long as mako was already running, using makoctl reload.

Adding this to /etc/apparmor.d/local/fr.emersion.Mako solved it for me:

# File ~/.config/mako/config is a symbolic link to this
owner @{HOME}/.cache/mako/config r,

Generating the actual file maybe is a more viable solution. 🤷

[emersion]

AppArmor support has been dropped: #426

[rileyrg]

Just an FYI, this problem still exists with the mako shipped with Ubuntu

Linux um690 5.19.0-29-generic #30-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 4 12:14:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Compiling from source and replacing it worked

[fluix-dev]

That just means they have an older version.

[op]

Seems like the AppArmor specific files can linger around on Ubuntu.

apt purge mako-notifier && apt install mako-notifier

Reported upstream. See https://bugs.launchpad.net/ubuntu/+source/mako-notifier/+bug/1992795