WSL 2 Loses Files and Images Without Warning
This ticket re-ups issue #4974 that was closed with no resolution to the acute, unrecoverable data loss episodes reported by multiple users including myself.
The dissembling by @bpulliam in the original ticket is unacceptable. 4974 is a significant locus of user feedback on these problems, and should remain open and active. Microsoft's inaction ruins the risk proposition of using an otherwise powerful technology. At least some of the failure cases could be fixed with simple, compatible, user-visible logic changes.
Did user run any command which led to that data loss? Or is the data automatically deleted by operating system?
Did user run any command which led to that data loss? Or is the data automatically deleted by operating system?
Please read the predecessor ticket for history. It has multiple reports of data summarily deleted as a side effect of apparently unrelated activity. The wsl --unregister command is extremely dangerous as it will delete whole WSL 2 images unrecoverably in one command with no option to confirm, or to archive the data.
The request would be similar as this https://github.com/microsoft/WSL/issues/8992
Users who run --unregister are expected to know what --unregister does. Changing the behavior to prompt for confirmation would break a lot of automation so it wouldn't be an option anyway.
I previously described options for --unregister (such as archiving, not deleting by default, with appropriate messaging; separate option to delete archived images) that would both preserve data and compatible behavior in current automation.
The point remains that data under WSL 2 sometimes disappears without notice or explicit action. I mentioned wsl --unregister running as a side effect in my scenario as one possible explanation. Its effects match the de-registration of the VM and removal of the image I observed.
such as archiving, not deleting by default, with appropriate messaging; separate option to delete archived images
That's a good idea. Though there are options to backup the ext4.vhdx file and re-register it in WSL2. Adding any archiving feature may be same as automatic backup by OS. Let see what WSL devs think.
Backup is a best practice. In an enterprise, it's out of date to place that responsibility on the end user, yet several do. Home-rolled backup schemes tend to have flaws. Also, the large size of image files (think 80GB for a professional workload), makes manual backup tedious and easy to forget. Cloud storage for VMs run locally isn't there yet.
This is a case where a little added safety to a core command can prevent a lot of damage. Microsoft usually goes out of its way in its UX to ensure positive user intent for operations that risk data. wsl --unregister should follow the same practice.
I share your frustration. We've identified an issue in the app model that somehow decides for some reason decides to "reset" application state on OS upgrade. We're engaged with the owning team to try to identify the reason for this.
@benhillis, it's good to read acknowledgement of a need for action on these issues. Thank you for your post. If you can suggest any use cases we can try to diagnose problems (on expendable data!), please do!
Would we look for any fixes first in a Windows Insider build?
@TW4177 - the team that owns the app migration code really needs a repro. If it's possible to come up with reproducible steps, that would be awesome although I imagine it will be difficult since it has to do with a build-to-build upgrade.
@benhillis I would direct them to the discussions in #4974; there are several somewhat well-described scenarios. I demo'd the behavior of wsl --unregister in that ticket; it and any added safety hardening are repro-able at will. My VM loss occurred after switching the physical machine and my login account to a new AD domain.
Both my colleague and I had our WSL2 volume deleted entirely immediately upon switching from logging in to Windows/AD using the classic DOMAIN\username format to using UPNs, i.e. [email protected]. The AD user account was the same for both username formats.
This change to the username format was something that had been requested by our central IT.
I beg the developers to please let the users know that wsl --unregister <distro-name> deletes the entire distro. Currently no warnings are displayed.
Last week I was readding an issue on how fix a GUI issue #8525 at 1am, and honestly executing wsl commands without reading the context deeply as it was late. I know that was my mistake, but I never imagined that one of those would delete my entire distribution with all my work without even a warning. ... I had my Ph.D. dissertation there 🥲.
I lost all my user account of Ubuntu 20. Only user is wslg. Happened 2nd time, after a restart. This is nuts. It's a VPN-controlled machine, so I'm not sure what updates were in the background but I suspect it's unrelated to that.
Edit: after a restart, it mysteriously reappeared. ¯_(ツ)_/¯
I just encountered this issue today, here is everything I know regarding my case:
- I use Windows 10 Home Edition, version
22H2, OS build19045.2965, Windows Feature Experience Pack1000.19041.1000.0 - I have two local Windows sessions, a
Privateone and aWorkone - Both the
PrivateandWorksession had aUbuntu-18.04running onWSL 1
Private | Work
------------------------------------
Ubuntu-18.04/WSL1 | Ubuntu-18.04/WSL1
- Because I needed to use Docker for a project I tried multiple times to upgrade the
Worksession'sUbuntu-18.04toWSL 2, each time to no avail (the upgrade process froze for multiple hours) but also without any side effect on my data. I never tried to do anything with thePersonalsession'sUbuntu-18.04until recently - Last month (April, 25th) I gave up with upgrading my
Worksession'sUbuntu-18.04and installed aUbuntu-22.04running onWSL 2in parallel. There was no issue setting it up and everything worked as intended
Private | Work
------------------------------------
Ubuntu-18.04/WSL1 | Ubuntu-18.04/WSL1
| Ubuntu-22.04/WSL2
- Last week (May, 13th) I needed a newer version of Ubuntu in my
Privatesession so I tried the upgrade process and this time it worked, getting my privateUbuntu-18.04running onWSL 1to aUbuntu-22.04running onWSL 2. As the files for those are stored inAppDataI was not worried about accidentally ruining anything on myWorksession
Private | Work
------------------------------------
Ubuntu-22.04/WSL2 | Ubuntu-18.04/WSL1
| Ubuntu-22.04/WSL2
- This morning (May, 15th), I boot up my
Worksession'sUbuntu-22.04only to be greeted with the new account setup prompts, as if everything I did on it since last month never happened
Private | Work
------------------------------------
Ubuntu-22.04/WSL2 | Ubuntu-18.04/WSL1 <= this one is unaffected
| Ubuntu-22.04/WSL2 <= this one got wiped out/reset
- When looking at the WSL files for this installation they are all marked as being created at either the time I opened my
Worksession or the time I openedUbuntu-22.04for the first time on that day
Fortunately I did not lose any important data but this is still setting me back a few weeks in terms of setup and local dev environment; not to mention the trust I lost in WSL as a tool.
Does this issue happen with Ubuntu distributions only?
I tried the upgrade process and this time it worked
How did you update - from Windows Store or with apt upgrade command?
Does this issue happen with Ubuntu distributions only?
I only ever used Ubuntu on WSL, and seem to remember a lot of people who had this issue did too. Whether there is a link or Ubuntu is just over-represented for WSL users in general is something I do not know.
How did you update - from Windows Store or with
apt upgradecommand?
I did not use the Windows Store at any point. To upgrade my Private system, I did an apt update, apt upgrade then a do-release-upgrade cycle twice, to go from Ubuntu 18 to 20 then 20 to 22.
Users are still not warned that wsl --unregister will destroy everything in the distro. This is very dangerous and high risk.
Posting here to register my complaint. I've posted my story in #4974 too. At least half a dozen times now, WSL2 spontaneously resets to factory default settings and content. This is absolutely not acceptable. It seems to happen mostly (if not exclusively) when I switch from WFH to working in the office, and sign into the domain there.
I've never used wsl --unregister and use apt exclusively for updating stuff.
Adding to the choir, I guess. At this point I can't retrace all my steps perfectly, but it started with trying to update through wsl --update, which did not work ("A specified logon session does not exist. It may already have been terminated.") After managing to get a kernel update in place, it seems like the entire ext4.vhdx got wiped and reset ("An error occurred mounting one of your file systems.") Could be user error on my part, for sure, but nothing through this process gave me any indication that this would be dangerous.
After testing some proposed solutions of remounting or resetting WSL2, I've resigned to set up my dev env from scratch again.
I'm having a serious problem with missing project folders. Here's a record of hopefully fixing it though without opening a new issue.
A project code folder under ~/Projects/ was missing after I updated Windows and tried to edit the code with VScode again.
Your Windows build number: Microsoft Windows [Version 10.0.19045.5131] Update Record: November 12, 2024—KB5046613 (OS Builds 19044.5131 and 19045.5131) and November 12, 2024-KB5046542 Cumulative Update for .NET Framework 3.5, 4.8, and 4.8.1 for Windows 10 Version 22H2
What you're doing and what's happening: I used the distro ubuntu 18.04 in WSL for a week straight and cloned a project from github, using the VScode remote plugin to connect to WSL. on 11/14/24 I closed all files, VScode, and used sudo shutdown now to shut down ubuntu. and then did a windows system update. Restarted WSL and tried to open VScode in the project folder,I found that I could not find the cloned project under ~/Projects/.
What's wrong / what should be happening instead: It doesn't clear whether some unwarned action deleted the project folder, or whether ubuntu's virtual hard disk didn't save it in time so that it's still the version before the project was cloned.
Strace of the failing command, if applicable:
For WSL launch issues, please [collect detailed logs]:
Unlike most of the issues with #4974 , the Ubuntu distribution doesn't reinstall automatically. But similar to #4974 , I lost an entire project folder that I had recently cloned from Github.
thanks for posting this issue, I fully agree with the request! I ran into some (partially recoverable) data loss after trying to solve https://github.com/microsoft/WSL/issues/12679 by mistakenly calling the unregister command.
I would have expected that this was the MS way:
This is a case where a little added safety to a core command can prevent a lot of damage. Microsoft usually goes out of its way in its UX to ensure positive user intent for operations that risk data.
wsl --unregistershould follow the same practice. https://github.com/microsoft/WSL/issues/9830#issuecomment-1480240856
Where is the "Are you sure", "OK" or "Cancel" UX for this command? Can they not add another flag to force it for automations?
I have been using WSL without problems for some years but I may be better off by migrating my workstation altogether.
Same, I've lost all of my workspace projects folders and also all docker images which has been installed on wsl 2 are gone.
Even that .ssh is gone but oh-my-zsh is there.
I think after update it got recovered from last snapshot of ext4 which has been done by windows itself. (i didn't call any snapshot)
I never had any issue like as this with my Win 10, but Win 11 bro it's definitely something else.