Denied: qubes.UpdatesProxy

When trying to update TemplateVM I get this warning, that the connection to the Update Proxy is denied.

My system:

### Qubes Dom0 (Qubes R4.1)
[user@dom0 ~]$ uname -a 
Linux dom0 5.10.8-1.qubes.x86_64 #1 SMP Mon Jan 18 18:24:01 CET 2021 x86_64 x86_64 x86_64 GNU/Linux

### Update VM (sys-whonix)
user@host:~$ uname -a
Linux host 5.4.61-1.qubes.x86_64 #1 SMP Thu Sep 17 01:09:48 UTC 2020 x86_64 GNU/Linux

Anyone else with this issue?

Any specific information that I should provide?


EDIT: Some information:

qubes.UpdatesProxy policy

[user@dom0 ~]$ cat /etc/qubes-rpc/policy/qubes.UpdatesProxy 
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny

qubesctl [...] update.qubes-vm

[user@dom0 ~]$ sudo qubesctl --skip-dom0 --targets=fedora-32 --show-output state.sls update.qubes-vm
fedora-32:
  ----------
            ID: dnf list updates --refresh >/dev/null
      Function: cmd.run
        Result: False
       Comment: Command "dnf list updates --refresh >/dev/null" run
       Started: 22:40:23.101185
      Duration: 3238.605 ms
       Changes:   
                ----------
                pid:
                    1151
                retcode:
                    1
                stderr:
                    Errors during downloading metadata for repository 'fedora-cisco-openh264':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Errors during downloading metadata for repository 'fedora-modular':
                      - Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                    Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64 [Recv failure: Connection reset by peer]
                stdout:
  ----------
            ID: update
      Function: pkg.uptodate
        Result: True
       Comment: System is already up-to-date
       Started: 22:40:29.468223
      Duration: 2599.923 ms
       Changes:   
  ----------
            ID: notify-updates
      Function: cmd.run
          Name: /usr/lib/qubes/upgrades-status-notify
        Result: False
       Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
       Started: 22:40:32.068342
      Duration: 1361.085 ms
       Changes:   
                ----------
                pid:
                    1306
                retcode:
                    1
                stderr:
                stdout:
  
  Summary for fedora-32
  ------------
  Succeeded: 1 (changed=2)
  Failed:    2
  ------------
  Total states run:     3
  Total run time:   7.200 s

Still no real clue why this might be happening.

2 Likes

Did you ever figure this out? Im getting this all day.

OP’s UpdateProxy policy is missing rules for non-Whonix VMs. The rules say that any VMs with tag whonix-updateVM would use sys-whonix as their UpdateVM, but there are no rules that would match other templates that don’t have that tag.

Assuming you want to update the other templates using sys-net, two more lines could be added:

@type:template @default allow,target=sys-net
@anyvm @anyvm deny

This is explained in more detail here: How to install software | Qubes OS

1 Like

This isn’t right in 4.1.
The policy file framework has been updated to use a default unified file
under /etc/qubes/policy.d/90-default.policy.
If you want to make changes to the default policy, you create a NEW
policy file in that directory, numerically lower, and that will override
the default.
That separate Whonix file is unnecessary, since it is using the old,
deprecated, form, which will be used under 4.X, but dropped in 5.0. Whonix
treatment is correctly set in the default file.

SO, to anyone having this problem, let’s get some hard information:

  1. Confirm which version of Qubes you are using.
  2. Does the error affect all templates? If not, which are affected?
  3. For templates which show the error, what is the output of qvm-tags?
  4. Are you updating over Whonix?
  5. Have you made any changes to default policy?
  6. What template are you using for the UpdateProxy - by default this
    will be sys-net unless you opted to update all templates over Tor.
1 Like

I have the same issue. I’m using Qubes 4.1. The error is: Denied: whonix.NewStatus. It happens when I open the whonix-gw-16 template, whonix-ws-16 template and any other VM based on whonix-gw-16 or whonix-ws-16. Never changed any policy, Just updated all vms. The error appears when shut down or start a vm(based on whonix templates). I’m not updating over tor.

Same issue here after cloning sys-net to seperate wireless and wired connectivity.
Nothing can update except dom0. No idea what to do. Default Fedora-34 AppVMs still have connectivity but AppVM’s based on minimal templates do not even connect to internet anymore.
Feels like a global pref issue but can’t find nor do I know Qubes enough to know what is wrong.

Yet no one expecting @unman’s help to specifically answer his questions.

Same Issue here after deleting sys-net and creating sys-net-lan and sys-net-wlan. Fresh 4.1 install Debian templates only.
I also edit /etc/qubes/policy.d/90-default.policy and changed
qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net
to
qubes.UpdateProxy * @type:TemplateVM @default allow target=sys-net-wlan

I stumbled upon this bug a day before and thought i somehow trashed my qubes install (playing a lot with saltstack latley) so i did a fresh install yesterday, but now its there again…
Maybee i missed something in the minimal templates to install, but even if i switch apvm templates back to default debian-11 the error seems to persist.

Thanks for any help on this

Still can’t figure this one out.

Anyone know how to create sys-net and sys-firewall from scratch without full reinstall. qvm-create commands I find don’t work on 4.1…

Thanks!

Thanks

some progress here, at least template updates are working if i activate the “qubes-updates-proxy” service in the qube thats defined in /etc/qubes/policy.d/90-default.rule