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+.
Hi @rustybird,
after upgrading from firefox-esr 128 to 140 I receive the error message again: “Failed to read configuration file. Please contact your system administrator.”
I am using Split browser v0.16.6.
Maybe something has changed again since Firefox 136?
1 Like
No.
ESR stores it’s configuration in different place than normal releases.
Indeed Firefox 138+ broke Split Browser again. Now it’s fixed in v0.16.7. Thank you for the report!
Seeing “Failed to read configuration file” means that the file is present in the right location, but there’s been some sort of error processing it. Sometimes due a breaking change like this one.
2 Likes
Awesome, thanks for fixing this so swiftly!
I wanted to take this opportunity to thank you.
I’ve rebuilt a bunch of my VMs, particularly ones having to do with Firefox, and was continuously wrestling with this message–totally unrelated to split browser! I solved those problems, then tried running split browser and saw the message again, and thought it was MY fault. Eventually I satisfied myself that the config files were there, so then I started commenting out parts of them and I discovered this part of the runtime JS file was borked (that file is a combo of this one you fixed plus all the numbered files in another directory)…and I came here and found the fix.
Turns out that no THIS TIME for once it wasn’t my fault. Firefox. They seem to be learning from Micro$haft.
Oh, I can’t even be mad at Firefox for this. After all, it’s me who’s poking around in its private interfaces. When the Firefox developers got rid of classic XPCOM extensions they did so to have more freedom in refactoring those interfaces and cleaning up the code, which apparently they’re doing. Good for them.
Fair enough.
I’ll be honest, I can’t understand half of what you did there, particularly in the bash scripts. I get the general gist, and that’s about it. And I got to remind myself of the multiple files one can use to configure firefox…I’m not sure how it got to be that way or whether it even makes sense (two files could make sense if you want sysadm configuration as well as user configuration).