Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persist /mnt/wsl mountpoints #5851

Open
giggio opened this issue Sep 3, 2020 · 9 comments
Open

Persist /mnt/wsl mountpoints #5851

giggio opened this issue Sep 3, 2020 · 9 comments
Labels

Comments

@giggio
Copy link

giggio commented Sep 3, 2020

Is your feature request related to a problem? Please describe.

In WSL2, I'd like to be able to share my home directory between distros. So when Ubuntu (my main distro) comes up, it adds a symlink from /mnt/wsl/homeuser/ to /home/user, and when OpenSuse comes up, it also mounts from /mnt/wsl/homeuser/ to /home/user.

Describe the solution you'd like

I understand /mnt/wsl enables the sharing between distros but unfortunately /mnt/wsl uses tmpfs, so when wsl shutsdown you lose everything that was there.

Describe alternatives you've considered

I could host the files on my main distro (Ubuntu) and share from Ubuntu to /mnt/wsl/homeuser/, and when OpenSuse comes up, it does the opposite. Unfortunately, for that to occur, Ubuntu must come up first, and must stay up, consuming memory and cpu cycles.

Additional context

Initial request started at #5177. Also related to #689 and to a possible wsl --mount described in MicrosoftDocs/WSL#824.

@stefanloerwald
Copy link

Is there a workaround for this? I need to be able to persist a folder in /mnt/wsl for kubernetes/docker-for-win. Actual folder can be elsewhere, but I at least need a way to persistently mount bind in /mnt/wsl.

@stefanloerwald
Copy link

Maybe you have an idea for a workaround, @therealkenc ?

@therealkenc
Copy link
Collaborator

Use .bashrc and /etc/suders tricks, same as always for what-would-be normally a systemd thing. Analogous firing up (say) sshd et cetera at first launch.

@TBBle
Copy link

TBBle commented Feb 8, 2021

/mnt/wsl should really only be used for mounts, both bind-mounts across WSL2 distros (the original use-case per #4577 (comment)), and wsl --mount, not for actually storing data. Persistent data storage outside a distro falls under #689 (per #5177 (comment)), but the mount points also need to be recreated on startup, for use-cases like Docker Desktop kubernetes hostPath mounts that reference other distros, see docker/for-win#7023 (comment).

This introduces a minor ordering issue, as all the mounts need to be up before any distribution starts (the k8s hostPath PV use-case from #5177), but of course the mount has no real way to know which distribution is the source of the mount (it's just a bind-mount between two mnt namespaces); it can't rely on running distribution startup scripts, as it wouldn't know that it needs to start docker-desktop last so that its mounts into other distros function correctly.

@autoferrit
Copy link

Maybe an option here would be to follow some XDG_ standards? Maybe the HOME dir for each distro is their own so they can have what it needs to be able to startup. but we can share things like ~/.config or ~/.bashrc etc? One issue going this way I see is that most times, we use .bashrc/.zshrc/etc to run out own startup scripts. So that might be hard.

Maybe, when a distro is first setup, it has it's own dedicated HOME as normal. then if you want to then mount some other partition/folder/path to $HOME then let them do it. if it doesn't start correctly and a mount is detected at $HOME we can then supply an error stating as such. Leave it up to the developer to manage their home dir if they decide to do that. I think most that have this kind of setup would understand the issue.

Another option, what if we have a second user in /home that has the minimum files needed to start, and uses that if the default users home dir is not present or empty. It could be read only to make sure it doesn't get messed with. If we are able to just mount an external device for storage for HOME, it shouldn't matter what distribution it belongs to right? since it acts like it is a mounted partition or disk. Which linux handles anyways.

Another issue here is where do we create said data/home partition? Seems to be we would have to deal with that inside wsl. So maybe like using docker we can create a persistent drive with the wsl command and then copy HOME to it, then tell wsl to mount it to HOME?

@TBBle
Copy link

TBBle commented Mar 29, 2021

Another issue here is where do we create said data/home partition? Seems to be we would have to deal with that inside wsl. So maybe like using docker we can create a persistent drive with the wsl command and then copy HOME to it, then tell wsl to mount it to HOME?

This is a use-case for #689, per #5177 (comment): A way/place to store data inside WSL but outside any particular distro's storage, so that it can be shared with all distros without needing to start a particular distro first.

Then you would just need what was originally described in this ticket: When a distro starts, before you access $HOME, you replace with with a symlink/bind-mount to wherever that block device is mounted. (Which could be /mnt/wsl, but that will depend on the way #689 is addressed, and if necessary any follow-on work to auto-mount such block devices).

@b-hayes
Copy link

b-hayes commented Sep 7, 2021

if you just want to share small files such as .bashrc and other config files just store them on /mnt/c/.
I use /mnt/c/devtools (c:\devtools) for my bash profile special configs and my entire collection of bash scripts.
My distros just source /mnt/c/devtools...../.bashrc and this is also git repository I sync across multiple machines all using multiple wsl distros.

All my custom scripts reside in NTFS and are accessible by all distros and git bash and PowerShell simply because I added the bin folder to the windows env path.

I have found no performance impact at all, my distros still start and run my scripts instantly.

PS: another trick I do is make all distros use git credential helper from windows and windows composer.phar so they never need to ask for git authentication once windows has triggered a browser sign in.

@guba-launikda
Copy link

@giggio Did you ever find a solution to this? I can't believe I'm asking about this years later haha

@giggio
Copy link
Author

giggio commented Feb 18, 2025

@giggio Did you ever find a solution to this? I can't believe I'm asking about this years later haha

It's been a while since I requested this, and since I haven't tried it again. I don't know if any of the new features would enable it, but AFAIK this is still not possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants