TLDR
Be aware that the current whonix-*-18 family of community templates does not use the standard/traditional default user user, but one named sysmaint, implying a need to adapt user space system maintenance using Salt.
Detailed Comment
On my entirely Salt-managed QubesOS setup I recently upgraded to QubesOS 4.3 and the whonix-*-18 template family.
A whonix-workstation-* template managing Salt state read like so:
update torbrowser:
cmd.run:
- name: update-torbrowser --noask --noaskstart --onion --update --only-if-newer
- runas: user
As update-torbrowser is explicitly designed to run in user space (and fails when called as root), the runas parameter ensures switching from Salt’s default execution as root to the given user. This kept failing with various disk access permission issues (in particular to /var/cache/tb-binary/.cache/tb/*) , which send me into hours of debugging including studying documentation, back and forth with Gemini et al. etc. - I learned quite a bit, but none of the leads from the process solved my problem.
I finally noticed (by serendipitously paying attention when opening a terminal in whonix-workstation-template-18) that in divergence from other templates (and the preceding whonix-*-17 family of templates), the terminal in the template used NOT user, but sysmaint as the login user. Thus, simply adapting my Salt state to
update torbrowser:
cmd.run:
- name: update-torbrowser --noask --noaskstart --onion --update --only-if-newer
- runas: sysmaint
solved all my issues.
I am not sure whether this change of login user is a) intentional and b) announced anywhere and document my journey here for saving others running into similar issues some time.