Doesn't Downloads get clobbered by Chrome whenever it feels cramped for space? Is there somewhere under cryptohome we could use instead? 

yes, Downloads is free to be clobbered by design.  i'm not sure putting it somewhere else in the encrypted homedir that is outside the reach of the user is that useful, and if the system is out of space, wouldn't help in that case either.

I agree with Mike that Downloads feels like the right place.  We currently create a directory named "Recovered files from google Drive" when something goes wrong in drive sync.  So another one named something like "Recovered Linux Files" or "Backed up Linux Files" would be along the same lines.

Does anyone know how we would tell that the VM/container has been disabled?

i think the only scenario we're looking at is toggling the Linux(beta) in settings ?  if you're using crosh/vsh to delete things by hand, you can handle backing things up too.

The case we care most about is when Crostini is disabled by policy, as users might not have a chance to get their stuff out.

If that needs to be automatic we need some signal. I guess we could do something at startup (or whenever policy is applied) and if there is a container but containers aren't allowed by policy, do our thing then.

Alternatively we could make it really simple and not do anything automatic. I.e. if an enterprise is about to disable something they give their users some notice and ask them to save their stuff. I think something like that happened with android containers on personal profiles a while back.

Tom, do we need to make it automatic?

Can anyone confirm, would it be the policy setting cros.device.virtual_machines_allowed which would need to watch for any change?

There are a few other features/prefs that are currently required at least for FilesApp to enable the integration.
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/crostini/crostini_util.cc?l=83-100&rcl=abf161d8e31c25ff09e2b96ebc14d8f5df197045

I didn't really mean to take ownership of this issue before, so releasing for now.  I'm not sure if the work here will involve the FilesApp at all.  For me, it looks like we might not need a technical solution if the solution is that policy makers/changers just give warning to their users.  Or if we do add something for this, then I would expect a dedicated dialog/script with an scp command is probably a better solution than any integration with FilesApp.

IIUC, you don't need to start the container to get the $HOME directory out of it. But I'm pretty sure you do need to start the VM (which we control, so it's not a security problem).  So you *should* be able to start the VM, then mount the container image inside of the VM and then extract the $HOME dir from that.

Adding Dylan who can give more details on that.

Mounting the disk image in the VM without running any containers is possible. However, ssh is currently run from inside the container so we'll need a different solution to get the files out in that case.

Tom - any feedback about #6? In particular, does this have to be automatic?

Has there been any development on this bug? It's 7 months old at this point.

See crbug.com/912638 for work to export and import containers which provides a similar feature.