[SOLVED] Persisting specific wifi connections in disposable sys-net

skyhawk · January 2, 2026, 7:56pm

So I’m sure I must be doing something stupid here, but I’m losing my mind.

From a fresh install of Qubes R4.3.0, with selected Disposable sys-net, I’ve done the following:

cloned default-dvm to sys-net-dvm
Assigned sys-net to use the sys-net-dvm template

Connected to my home Wifi
Copied the contents of sys-net:/rw/config/NM-system-connections/homewifi.nmconnection to sys-net-dvm:/rw/config/NM-system-connections/homewifi.nmconnection

ensured sys-net-dvm:/rw/config/NM-system-connections/homewifi.nmconnection is owned by root:root with perms 0600

Powered off sys-net-dvm, then rebooted sys-net.

The file is there in sys-net. I’m looking right at it. The contents are right. The ownership is right. The permissions are right. Yet this file is utterly invisible to NetworkManager no matter what I do. What the hell am I missing?

Atrate · January 2, 2026, 8:13pm

While I do not know what your issue is, you can instead do the following to achieve your goal in a way that I have verified works and does the same thing (makes sys-net “disposable”) while not requiring a whole new DVM template.

Have a sys-net qube that’s an AppVM (NOT Disposable)
Add your connection the way you would normally (just by connecting to it)
Execute the following commands in dom0:

qvm-features sys-net custom-persist.networkmanager /rw/config/NM-system-connections
qvm-service -e sys-net custom-persist

Reboot sys-net
Profit! Now you can add and remove NM connections in sys-net and they get persisted but nothing else does.

Context:

github.com/QubesOS/qubes-issues

Add common use cases for minimal state app qubes to documentation

opened 07:46AM - 13 Aug 25 UTC

Atrate

C: doc P: default

### The problem you're addressing (if any) As mentioned in the original issue (…https://github.com/QubesOS/qubes-issues/issues/1006#issuecomment-3182154768): > Solution: The NetVM (in a minimal-state state) would just store network settings, but not anything else. It would be much harder to store a persistent malware that survives reboot, so such multi-stage attack is much less likely to be successful. That's a great idea, but it's not obvious how to set that up. ### The solution you'd like Make a documentation with common use cases for minimal state app Qubes, e.g. which directories to make persistent for NetworkManager, which to make persistent for common e-mail or communication software (or just ~/.var for flatpak apps), etc. ### The value to a user and who that user might be Anyone who wants to use this feature effectively without having to experiment or dig through lots of documentation of e.g. NM. ### Completion criteria checklist _No response_

parulin · January 2, 2026, 8:52pm

You can try this?

skyhawk · January 2, 2026, 11:05pm

Doesn’t help. I’ve got my configuration down to [wifi] with an ssid, and [wifi-security] with key-mgmt and psk, and NetworkManager is completely oblivious to the file’s existence.

skyhawk · January 2, 2026, 11:20pm

Okay, I think this is actually something in Qubes not working as intended, or at least not working as previously described.

If I run, in sys-net

sudo cp /rw/config/NM-system-connection/mynetwork.nmconnection /rw/config/NM-system-connection/fixthis.nmconnection, followed by systemctl restart NetworkManager, sys-net now reports 1 connection profile and automatically connects to my wifi.

Files populated in /rw/config/NM-system-connection at boot-time from the dvm-template are not recognized by NetworkManager for some reason.

Ownership is the same. Permissions are the same. Contents are absolutely identical.

solene · January 3, 2026, 12:11am

I bet in a selinux issue? It’s not enough to make the permissions right, you need to put the selinux flag to allow network manager to use the file.

skyhawk · January 3, 2026, 1:15am

You’re awesome!

In sys-net-dvm - sudo fixfiles restore /rw