`rm` errors when running `update-torbrowser` on a fresh `whonix-workstation-18` template

Euwiiwueir · January 9, 2026, 4:56pm

See:

dom0$ qvm-run --pass-io whonix-workstation-18 '/usr/bin/update-torbrowser --onion --only-if-newer --noask --noaskstart'
INFO: ARCH 'x86_64' detected.
INFO: ARCH_DOWNLOAD 'linux-x86_64' detected.
INFO: CURL_PROXY: '--proxy
http://127.0.0.1:8082/'
INFO: Automatically setting download folder to '/var/cache/tb-binary', because running inside Qubes Template but not run from postinst. This is useful so you get up to date versions of 'Tor Browser' in newly created App Qubes inherited from updated Templates.
More info: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Qubes-specific
INFO: TB_FORCE_INSTALL is set to '1', therefore setting TB_INPUT to 'none'.
rm: cannot remove '/var/cache/tb-binary/.cache/tb/temp/pv_wrapper_fifo': Permission denied
rm: cannot remove '/var/cache/tb-binary/.cache/tb/temp/tar_fifo': Permission denied
rm: cannot remove '/var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder': Permission denied

The rm errors are new, I think (or maybe I’m paying closer attention?). Should I be invoking this as root or sysmaint instead of as user?

Thanks!

Patrick · January 10, 2026, 2:27pm

We’ll look into this.

arraybolt3 · January 11, 2026, 2:19am

I can’t reproduce this whether I boot whonix-workstation-18 in user or sysmaint mode. Can you run stat /var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder and share the output here?

Euwiiwueir · January 11, 2026, 4:32pm

Thanks for checking. Ok, looks like I edited out something important in my first terminal transcript above (whoops). The invocation that produced the “Permission denied” errors was explicity user. Running it again that way now:

[user@dom0 ~]$ qvm-run --pass-io -u user whonix-workstation-18-test '/usr/bin/update-torbrowser --onion --only-if-newer --noask --noaskstart'
INFO: ARCH 'x86_64' detected.
INFO: ARCH_DOWNLOAD 'linux-x86_64' detected.
INFO: CURL_PROXY: '--proxy
http://127.0.0.1:8082/'
INFO: Automatically setting download folder to '/var/cache/tb-binary', because running inside Qubes Template but not run from postinst. This is useful so you get up to date versions of 'Tor Browser' in newly created App Qubes inherited from updated Templates.
More info: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Qubes-specific
INFO: TB_FORCE_INSTALL is set to '1', therefore setting TB_INPUT to 'none'.
rm: cannot remove '/var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder': Permission denied

(The pv_wrapper_fifo and tar_fifo errors not showing up this time.)

If I remove the explicit -u user, then no error :

[user@dom0 ~]$ qvm-run --pass-io whonix-workstation-18-test '/usr/bin/update-torbrowser --onion --only-if-newer --noask --noaskstart'
INFO: ARCH 'x86_64' detected.
INFO: ARCH_DOWNLOAD 'linux-x86_64' detected.
INFO: CURL_PROXY: '--proxy
http://127.0.0.1:8082/'
INFO: Automatically setting download folder to '/var/cache/tb-binary', because running inside Qubes Template but not run from postinst. This is useful so you get up to date versions of 'Tor Browser' in newly created App Qubes inherited from updated Templates.
More info: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Qubes-specific
INFO: TB_FORCE_INSTALL is set to '1', therefore setting TB_INPUT to 'none'.
INFO: Not running inside Qubes Disposable Template, ok.
INFO: Using stable version. For alpha version, see: https://www.whonix.org/wiki/Tor_Browser#Alpha
INFO: Running connectivity check...  Downloading...: 'http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion'
INFO: CURL_OUT_FILE: '/var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder'
INFO: Connectivity check succeeded.
INFO: Find out latest version... Downloading...: 'http://ot3ivcdxmalbsbponeeq5222hftpf3pqil24q3s5ejwo5t52l65qusid.onion/torbrowser/update_3/release/download-linux-x86_64.json'
INFO: CURL_OUT_FILE: '/var/cache/tb-binary/.cache/tb/RecommendedTBBVersions'
INFO: Previously downloaded version: '15.0.3'
INFO: Currently installed version  : '15.0.3'
INFO: Online detected version      : '15.0.3'
INFO: Skip downloading: current 'Tor Browser' '15.0.3' is already up-to-date.

If I add -u user back and run again, same permission denied error as above.

Here’s the stat after a failure:

[template workstation sysmaint ~]% stat /var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder
  File: /var/cache/tb-binary/.cache/tb/temp/tbb_remote_folder
  Size: 23012           Blocks: 48         IO Block: 4096   regular file
Device: 202,3   Inode: 786865      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/sysmaint)   Gid: ( 1001/sysmaint)
...

My takeaway now is I should not try to run update-torbrowser as -u user as I had in whonix-workstation-17. Rather -u sysmaint, or let the template choose its default. Is that right?

arraybolt3 · January 11, 2026, 6:58pm

OK, I think I know what’s going on now.

There’s actually a script in tb-updater that is supposed to fix permission problems with /var/cache/tb-binary, called tb-permission-fix.

github.com/Kicksecure/tb-updater

usr/libexec/tb-updater/tb-permission-fix

master

#!/bin/bash

## Copyright (C) 2019 - 2025 ENCRYPTED SUPPORT LLC <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

## This script is run by both:
## - torbrowser
## - update-torbrowser

#set -x
set -e

if [ -f /usr/libexec/helper-scripts/pre.bsh ]; then
   source /usr/libexec/helper-scripts/pre.bsh
fi

## Not needed?
## https://forums.whonix.org/t/tor-browser-permission-issue/17222/3
#rm --recursive --force /var/cache/tb-binary/.cache/tb/gpgtmpdir

This file has been truncated. show original

This script has to run as root in order to do its job, and is run in such a way that it does not know what user account invoked it. Because of this, it has to guess what user account to change the permissions to. Generally, this only matters on Qubes OS, because update-torbrowser doesn’t usually have to run as root anywhere else.

The current assumption has been that whatever the “default user” is, that’s the user account update-torbrowser will be running as. For this reason, tb-permission-fix reads the default-user value from qubesdb, and uses that as the user account to change permissions to. If you boot in “PERSISTENT Mode - USER Session”, this default user is user, whereas if you boot in “PERSISTENT Mode - SYSMAINT Session”, this default user is sysmaint.

What’s happening in this situation is you’re booting a template in sysmaint mode, but explicitly running update-torbrowser as account user. This means tb-permission-fix changes the permissions to allow access to the “wrong” account, and that’s what results in the errors.

The existing behavior is wrong, since it doesn’t tell the user about this caveat. As for how things should work, there are a couple of possibilities I can think of:

We could make update-torbrowser switch to running as user if run by account sysmaint. This would make it work in all scenarios, but I don’t really like this since this implies that the user account has full control over the Tor Browser binary for all user accounts, sysmaint included. Users who use StandaloneVMs and who also open Tor Browser in sysmaint mode could end up with sysmaint compromised by user in this scenario.
We could make update-torbrowser detect when it’s running under the “wrong” user account given the boot mode, and exit with a descriptive error message telling the user what to do. Personally I think this is the better option.