Context: So I’ve followed this tutorial (“How to install Windows qubes in Qubes OS | Qubes OS”) on how to create a HVM Windows VM and opted to follow the Windows Template tutorial too. I opted to not install the QWT because of the security warnings. I installed a version of Windows 11 and used a valid key to license it.
I’m having an issue when starting an AppVM that uses the created Windows Template VM as its template. As per the tutorial, I’ve moved the “C:/Users/” folder to the private storage “Q:”, in the Windows Template, using the .exe provided by the tutorial. The process seems to have been successful, but the AppVm cannot login to Windows. When starting the VM, the usual Windows login page appear (I’ve set no password and a local user) and it automatically tries to enter Windows normally (as I’ve set no password). This is then interrupted with the following text: “The User Profile Service service failed the sign-in. \n User profile cannot be loaded” and it locks me out again, preventing me from even reaching the desktop page.
I can use Windows normally in the TemplateVM, but cannot in any VM created using it. I think there’s something wrong with the way the private storage volume “Q:” is set to the AppVM, but I don’t really know how to troubleshoot it.
I’ve been searching online for something close to this problem in the qubes os forum, but haven’t found anything yet. Do you know what could’ve happened?
I have now checked this with a new Windows 11 template. After performing the directory relocation, drive Q: has, as is to be expected, a directory Q:\Users\, and in this directory, a public directory and a directory for the current user’s file, e.g. Q:\Users\USERNAME\.
But the current user has no access to this latter directory, and so no access to the user profile stored there! For the template, this does not seem to matter, because a copy of the profile can still be found in C:\Users\USERNAME\, but for any AppVM based on that template, this is fatal.
This situation can be changed by clicking on Q:\Users\USERNAME\ in the explorer. Then, a pop-up is shown asking if access should be granted, using administrator privileges for this operation. If this is done, the directory and its contents can be accessed. Any AppVM created after shutting down the template should be working.
I would be interested if this sequence of actions works for you, too. In this case, I’ll amend the documentation.
The error will not occur if the user disk is called Q: and is empty. So a reliable way to use the relocate_dir.exe utility is to format the use disk and give it the drive letter Q: before booting, using the windows disk manager.
In my template there seems to be no such an issue. The directory Q:\Users\user\ have already been set “full control” permission to the user. But as you said, if I remove the C:\Users\ shortcut folder, the template vm then breaks and do the exact same thing as the app vms.
I could try to replicate what you proposed in your second reply, but could you clarify it a bit more? I don’t remember exactly the way I did the setup for the “relocate_dir.exe”, but I think I did what you said. I formatted the disk as NTFS and renamed it to Q: before making the relocation.
Here are the steps, performed in Qubes R4.2.4 in a new Windows 11 24H2 VM, as far as I remember:
Copy relocate_dir.exe to C:\Windows\system32\.
In the Windows disk manager, set the drive letter of the private volume to Q:.
In the Windows Explorer, format Q: to NTFS.
In the registry editor, add the text to the DWORD value as described in the documentation…
Reboot. Observe a rather lengthy display of actions performed, showing first the copy operation from C:\users\ to Q:\Users\, then the deletion of the files in C:\Users\, and finally the creation of the link from C:\users\ to Q:\Users\. This list of actions must be shown; otherwise, something went wrong.
I hope this helps a bit.
The unknown account probably comes from some earlier actions and may refer to a previous user who was deleted in the meantime. I guess it’s of no importance.
As a reply, I redid the process being sure to format the private disk as NTFS and rename it to “Q:”. The process occurred successfully same as the last time. But the issue occurred again. I can provide the log file that is generated by the relocate executable if you need it.
I think I’ll just stick to use it as a standalone and copy the vm every time I need something specific for now at least.
I wonder if QWT will still have some updates on its drivers in the future, because the QSB-091 seems to be almost 2 years old already.
There’s something weird going on. Could you provide the log? I’ll see if I can find anything.
You could try the new alpha version of QWT 4.2.0, which seems to work quite well as long as you don’t select the option of installing the new graphics driver, which is still very experimental and unstable.
Please note that this version is currently offered for Qubes R4.3, but it works for R4.2.4 as well.
Thank you for providing the log file. Unfortunately, it does not show anything special — it looks quite okay, especially since it is quite similar to thge log file from my test, and contains just the entries that are to be expected.
There are, however, some locations in the system that might give you a hint at what could be wrong:
The directory Users on drive C: should be a link to Q:\Users\.
Ìn consequence, C:\Users\user\NTUSER.DAT should be the same file as Q:\Users\user\NTUSER.DAT, and it should have a rather recent date. This file contains the user part of the registry, i.e., HKEY\CurrentUser aka HKCU.
The protection of this file should allow full access for the user user (or what they are called) and for SYSTEM and administrators.
The system part of the registry should point to the directory containing this file: The registry value ProfileImagePath in the registry key HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ProfileList\S-1-5-21-...
should have the value C:\Users\user. The last part of the name of this key is the user’s SID, which contains three long number and then probably -1001.
I am afraid that if this is okay, too, I have no idea what else could be wrong, except that Windows altogether is a mess.
