same thing on a chromebook plus v2 @stable.
having to add back the shares every time is a pain.

Same issue on Lenovo c330. The killer about being limited on built in storage, and the higher tier storage plans being fiscally irresponsible for the average adult, is not being able to access storage devices we have for this very eventuality.

Zentaro - can you confirm that this is a bug, or perhaps functionality that is still being built out, or something else?

Thanks

It's a known limitation right now. Essentially the underlying reason is that we don't store the users password to disk. So after reboot/new login we can't remount the shares because we can't authenticate. That process happens very early during login controlled via the FSP layer.

This also occurs if for example you mount a share on one network, then logout and take your laptop to another network (eg. work vs home). If at the point of login the share isn't found, remounting will fail and we remove it.

crbug.com/913691 which is in progress now should land in 73 and modifies the way we handle "failures" during the remount process. This will still keep the share mounted in the files app, but we now added delayed authentication so that the first time you access it you will be prompted for the password. Or in the case of shares that weren't present before, renavigating will try again.

We can talk separately about the enterprise authentication cases and ongoing work there.