Split-browser permission denied issue

What am I doing wrong to get this error?

disp: /etc/qubes-rpc/split-browser-disp: line 9: /etc/split-browser-disp/23-librewolf.bash: Permission denied

I’m lacking any context to be able to help you.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

Check the output of ls -l /etc/split-browser-disp/ in the disposable template’s TemplateVM - all files there need to be readable by the VM’s default user. sudo chmod 644 /etc/split-browser-disp/* should ensure that.

1 Like

Wow. Thanks for your response. For the life of me I could swear i have never used this before to get the browser started…

Now, I have few issues:

~]$ split-browser
disp: JavaScript error: sb.js, line 21: TypeError: Cu.import is not a function

Then, opening the browser became painfully slow (like waiting for 40-ish seconds) and then getting “Configuration Error”

Failed to read configuration file. Please contact your system administrator.

Upon clicking “OK”, browser opens, but “ALT+B” doesn’t open bookmarks, but rather browser’s own Bookmarks menu. Needles to say I have all packages installed, and I just switched split-browser’s appVM’s template to new f41 split-browser template, while bookmarks are still there in appVM’s /home/user/.local/share/split-browser/ folder.

Interestingly enough, doing the same for tor based whonix dispvms (switching cloned appVM’s template to f41) works for whonix, since it’s still the same whonix dvm template.

Following the logic, it’s something with librewolf template, and I still have no idea what…

1 Like

Oh crap, Split Browser was simply broken on Firefox 136+ (and derived browsers). Thanks for the bug report! I’ve just pushed a new version 0.16.6 fixing this.

If you don’t want to wait for the update to become available in the contrib repo, you could manually apply the change to the file /usr/share/split-browser-disp/firefox/sb.js in the disposable template’s TemplateVM.

1 Like

Thanks for saving my sanity!
Do you have an idea why I had to make .bash files readable by the user group, while it’s nowhere in the manuals and while I strictly and routinely followed manual this time too?

Hmm, it probably was by setting the world readable bit that the chmod command made 23-librewolf.bash readable for the default user (assuming that the file is owned by root:root). The permission error only occurred for that one file, and since it doesn’t ship with Split Browser you had to create it yourself - maybe in a root shell session that had a too restrictive umask?

So, how would you properly create file /etc/split-browser-disp/21-librewolf.bash with content

SB_FIREFOX_DIR=/usr/share/librewolf
SB_FIREFOX=( ./librewolf )

in order to ensure file to be readable for the default user?

Something like

$ sudo -s
# umask 0022
# nano /etc/split-browser-disp/new-file.bash

You can also run umask without any arguments in the root shell to see its current value. (Usually it’s already 0022. It was just a guess that your shell might have configured it to e.g. 0027.)

Well, thanks for the tip. I’ve been contemplating this for several days and was trying to comprehend why this wasn’t my usual routine so far and now I have to do it, and I came up with no logical conclusion. I’ll wait for the official release and then try everything again from the scratch and will come back then to conclude hopefully.

Have you always used Split Browser with LibreWolf? If you used it with Tor Browser / Mullvad Browser / mainline Firefox before, you wouldn’t have had to create a new configuration file in /etc/split-browser-disp/ and so the permission problem (due to a restrictive umask or editor configuration or whatever) couldn’t have occurred.

Yes I have for years now. I have my detailed notes about whole Qubes system, so whenever upgrading, I’m just routinely and virtually blindly copy/paste procedures and after that just switching templates for existing correspondent dvm templates or appVMs. From time to time I update them when a change in a procedure is introduced, but this one doesn’t look like such a change.
It’s something with the librewolf template and I suspect this should be the lead, because I think this error is not related to split-browser, but to permissions in general:

Hmm what distribution is it based on? If it’s KickSecure they do indeed set the umask to a restrictive 0027 in some contexts, and there’s a recent change (not sure if it’s relevant): Fix umask for pkexec-run commands · Kicksecure/security-misc@612f5f9 · GitHub

That’s just the generic Firefox error message if the Mozilla AutoConfig file (sb.js) is broken, in this case due to the incompatibility of Split Browser before v0.16.6 with Firefox 136+.