Arch Linux User Repository

• Official Brave Browser packages in AUR - brave-bin (release), brave-beta-bin (beta), brave-nightly-bin (nightly)
• Official Brave Origin packages in AUR - brave-origin-beta-bin (beta), brave-origin-nightly-bin (nightly)
• Find answers - FAQ, Help Center
• Ask questions - Community
• Report bugs - GitHub
• Request features - GitHub
• Versions - the AUR package is updated when the public version for both architectures is updated

The PKGBUILD has not been updated to the 1:1.90.122-1 version

@Giraffe448 the PKGBUILD was updated for 1.90.122. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brave-bin is stale - I assume that's a caching issue with AUR.

The PKGBUILD has not been updated to the 1:1.90.122-1 version

@tournelhenry please report the issue on GitHub

After the last update, text rendering is fucked up on CachyOS

Update/Edit: It doesn't seem to be a Brave issue. Texts are also not rendering in Firefox pdfs too. Seems to be an issue with my system after an update. Sorry. The system is also logging me out under heavy loads

i have this crash when starting brave, any ideas ?

@SR-G please open a GitHub issue, including crash report ID(s)

$ brave
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help'

Help

Hello. Since yesterday, i have this crash when starting brave, any ideas ?

(process:11135): Gdk-WARNING **: 08:39:26.912: Cannot get portal org.freedesktop.portal.Settings version: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.freedesktop.portal.Desktop': activation request failed: unit is masked
[0408/083926.933079:ERROR:third_party/crashpad/crashpad/snapshot/elf/elf_dynamic_array_reader.h:64] tag not found
[1]    11135 segmentation fault (core dumped)  brave

umask is 022 currently. I doubt it's something specific with my system because if I remove the latest brave-bin package and manually install 1.82.170-1 using makepkg, the directory is created with the right permissions.

EDIT: In trying to record a video to show the process, I discovered that downloading the PKGBUILD script for version 1.82.170 from scratch and running makepkg -si yields the same result of a directory with 754 permissions.

It seems the only reason it was working fine is because I had a directory which contained the script and the files already downloaded. Installing from there still works fine.

In the end, it is probably my problem. Sorry to have bothered.

But it's strange because this is the only package that gives me this issue. I tested unsintalling unityhub as an example, cleared all cache, installed again and the directory for that one has the right permissions and runs without issue.

EDIT 2: I think I got it. ACL issue. My yay cache is redirected to a new drive in which I set specific ACL.

EDIT 3: It was indeed the ACL settings of the new drive. I moved the yay cache symlink to a different directory without ACL and now brave installs with the correct permissions. How UnityHub avoids this issue is unclear to me. Could be related to the first thing brave's script does of creating a folder, then copying it with -a.

@Corbent that does not appear to repro in a fresh archlinux container.

/opt/brave-bin, which starts as an empty directory created during prepare() and gets copied with cp -a does, at first glance, look sensitive to umask changes on the system where the package is built, but I couldn't reproduce what you're seeing. With umask 023, the package seems to be built with 754 permissions on the directory, but that still gets installed as 755. Might be an issue with my testing. I'll take a look at it when I have a moment. In the meantime, can you check if you changed your umask around the time 1.82.170 came out (18.09.2025)? I'm not aware of changes that would cause that, in AUR, or the release artifacts.

I've been having a problem for several versions now about permissions. When I install this package it goes into /opt/brave-bin and belongs to root. Which seems fine, it asks for sudo password in the last stage of installation as pretty much all packages do. But the permissions on the brave-bin directory (and all directories inside) are drwxrwxr--

So only root (and root group I suppose) have access. Which doesn't include my usual user. I'm not sure about manually changing the permissions as this could be a sign that something is wrong. Up until version 1.82.170-1 this permissions issue didn't happen.

I didn't report this earlier since I expected it to be a general thing, but until now the issue persists and I see no reports, so here it is. I guess people that have had brave for a very long time already have their directory permissions set and don't get overwritten.

In fact, when updating from 1.82.170-1 to new versions I got a warning during install saying that directory permissions in the system and the package differ 755 vs 754.