Change:
# The icon validator needs to access the gdk-pixbuf loaders in the Nix store # and cannot bind FHS paths since those are not available on NixOS. finalAttrs.passthru.icon-validator-patch <ins> # Try mounting fonts and icons from NixOS locations if FHS locations don't exist. # https://github.com/NixOS/nixpkgs/issues/119433 ./fix-fonts-icons.patch </ins> ]; nativeBuildInputs = [

Discussion:
Describe the bug Flatpak mounts /usr/share/icons and /usr/share/fonts to /run/host/share/icons and /run/host/fonts respectively. However, this doesn't work on NixOS since all fonts/icons are in their own directories in /nix/store. While the lack of icon theme in flatpak apps is not so a big problem, the lack of system fonts leads to inability to read text written in some languages. The font for Latin characters is Deja Vu is that case that is too bold and has bad readability (at least for me). I'm suffering from this issue for a long time and thought that at some point someone raise this or this will be fixed at some time by someone, but I can't take it anymore :( To Reproduce Steps to reproduce the behavior: any app from flatpak that it uses Deja Vu font and can't display various language families (e.g. CJK), can't display graphical symbols, etc. that it can't use system icons even if it tries Expected behavior Flatpak is patched so that it can read fonts and icons. Or some option that enables centralized storage of fonts/icons and Flatpak uses it. Screenshots ! ! How it looks like outside of flatpak: ! Notify maintainers Metadata Maintainer information:
Relevant source code: The directory can be overridden using a configure flag:
This probably won't help without some option to copy all the fonts to one directory... There's , but it links fonts, so flatpak apps can't access them :(
I recently switched from the nixpkgs spotify to spotify in flatpak and I didn't notice this issue until today, but it's a pretty severe issue. Here's an example of a Japanese artist's page when there is no access to system fonts for CJK fallback: !
My poor, temporary solution was to copy (a 118 MiB file...) to , which flatpak apps get automatic access to. Using a symlink doesn't work, since it links outside of what flatpak is allowed access to. A proper solution might involve collecting a list of all the store paths for system fonts, and building a big list of bubblewrap s that gets passed to flatpak, which could be done in the flatpak NixOS module.

For example:
I hope that will be solved once, since I don't really want to copy all installed fonts to home :(
Looks like I found a solution for myself that won't double occupied space... I copied the fontconfig module and modified it in a way so that it copies contents of all the font packages to one package and doesn't reference these original packages, so they're removed right after nix-collect-gabage. I also created a bind mount to avoid flatpak rebuild for myself. I think I will do something like this for icons as well.
So it is: Unlike the font one, it duplicates the icons, but I have only 300 MB of them (unlike fonts), so that's acceptable for me.
My solution: then enable the option for your application in flatseal.
That's not really a great solution since it pretty much eliminates the security benefits of running proprietary apps inside flatpak containers
I highly advise against doing that since that would defeat the purpose of using flatpak, A safer way of dealing with this issue is to download (or copy) the fonts you want your apps to use into either or and giving flatpak apps access to the location u choose via flatseal the same can be done with the cursor, again just download the theme u use, place it into or and giving the apps access to that in both cases you can either to that on a per-app basis or just add access to those folders in the global section
If you have home manager, you could try something like the following (untested): Or just add those in Flatseal. Or edit the file manually. That should be slightly safer.
Using to copy all fonts to the user's home directory can temporarily solve the font problem. Of course, this is not a long-term solution.
Doing this causes a lot of applications to break. Some apps such as Pika Backup and Clapper won't launch at all. For example, NewsFlash complains about the following: It seems the only reliable solution is copying the fonts / icons to my . Which really sucks.
I still use my own modules
In my case, icons are taking up way more space than fonts, so those modules don't really help much unfortunately.

Just in case it can be of use to anyone, I made a workaround for this issue using : The main trick here is that resolves all symlink, allowing them to be accessed without letting into the sandbox.
This works for me. Thank you very much!!!
Hope someone fixes this in nixos itself so we don't need the workarounds
This issue occurs mostly in Debian and openSUSE based distros with x11 fonts installed. Fedora and RHEL-based distros are usually not affected by default. Other distros may be affected if they have x11 fonts installed. The issue happens due to the following: flatpak apps loads, it will prioritize the system fonts installed in the host. the font is not found in the system, it will look at the user font configuration and font files. the font is still not found in the user space, the aliases for fonts will kick in. As long as there is an equivalent family of the target font, it will use that font. For example, in a Wikipedia webpage, the title of the topic uses 'Linux Libertine', 'Georgia', 'Times', serif; in that order. In default Debian and openSUSE installation Linux Libertine and Georgia are not installed. The next candidate is Times which is provided by an old x11 bitmap font. In Fedora, Times as x11 font is not present, therefore it fallbacks to serif which the flatpak runtime environment provides as TeX Gyre Termes. What we need is to remove x11 fonts so we can have that fallback mechanism just like with other distros. In Debian remove x11 fonts using: In openSUSE based distros, use this code:
The name of the issue implies flatpak can't access host fonts at all, including x11 fonts
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Any updates?
Works perfectly for me! Is it possible to make it also work with fontconfig? AFAIK fontconfig have the same issue with flatpaks right now.

This seems to trigger an infinite recursion with the mountpoint valid path check and ( I never set, and I also don't use ZFS) when there's a filesystem whose name (apparently) begins with a letter or with ( specific, yeah). I include some more detailed info below. (Not sure if this is an issue with NixOS or with the shared code (or something I messed up)... I could open a separate issue if it's the former.) Edit: I'm failing to make a properly shareable minimal example, sorry for that - so it's more likely that it's my fault than otherwise. But, in case anyone else stumbles upon this, setting the filesystem name to a known working name - such as instead of - while changing the attribute to the actual mount point seems to fix it. <details<summaryFull stack trace</summary<p</p</details<details<summary<codesystem/x11/fonts/fhs-</code(with = true;</codeelsewhere)</summary<pVerbatim copy of the suggested code: </p</details<details<summaryHardware config</summary<pCommenting out the line with makes the error stop. (Conversely, the error still happens when all lines but the one are commented out.) Replacing it with e.g. or or or or does not fix the error. Removing or adding a slash before the (or other letters) in in the name fixes it. </p</details
Hmm, today I got the same error while rebuilding my system, thought the issue was on my side since I changed a lot of stuff in my config.
That's not a good idea. Those configs are incompatible between fontconfig versions.
I'm also experiencing this same issue; from what I see, this happens when the bind mountpoint tries to reference , which fail to evaluate due to it trying to sort the (couldn't debug why prefix makes it fail though). For me, it's hard to implement the workaround of renaming the key and adding property, as most of my filesystems are folders mounted by 's option, which doesn't give an option to rename key and add the mount point. Another very ugly, impure approach is to replace with ; notice this doesn't update upon new system activation, so one needs to remount icons manually if willing to reload that mountpoint, but it removes the evaluation and fix the infinite recursion.

If doesn't work, then try building a custom env instead, like this: Then refer to it instead.
After a quick search, I found . I am not a developer, can anyone tell me can this option be used?
Unfortunately not, you can use it to change the path bind mounted by flatpak but it won't work on NixOS because an aggregated folder is a set of symlinks and regular bind mounting won't resolve them automatically
This also does not work, at least from what I can see. Infinite recursion error remains.
This is the best I could come up with as someone hitting the infinite recursion issue. I have replaced the with since that is the new default coming in NixOS 23.11 (and currently in NixOS Unstable). I have also hardcoded the packages with icons that Firefox needs in Flatpak (the cursor from GNOME and one for KDE, which I don't use). Additionally, I have updated the bind mount path to , since, for some reason, Firefox was not finding them at . Interestingly, if I try to do the same with the icons folder, it doesn't work. This works for the Firefox Flatpak, but the VSCodium Flatpak does not use the cursor icons for some reason. Anyway, hope this helps someone. Really looking forward to seeing if someone can crack the case on that infinite recursion error, to remove this package hardcoding workaround from this Flatpak workaround!
PR with (posting here to notify issue subscribers)
I've been having this issue with flatpak element. the cursor is the default wayland cursor instead of the gnome one.
hopefully this gets fixed soon
since soon isn't coming anytime soon it seems here's my temporary fix (this doesn't support fonts since I have no idea how to do so)
This issue has been mentioned on NixOS Discourse. There might be relevant details there: