While this issue observed,
- Install gedit from command prompt using sudo apt-get install gedit
- Observe UI icon in menu, open gedit
- Enter some content and save file
- Observe saved file from command prompt as shown in feedback report screenshot
- Open Linux Files folder from file menu and check for saved file
- no file observed(Check feedback report)

Feedback report: 
85525181642

I guess the file manager doesn't know about uninstallation, so it gets stuck with the old keys. Can work around with rebooting/signing out.

Signing out and in doesn't fix the issue. But it is resolved after rebooting the system.

I have verified that uninstalling and reinstalling causes errors on version 10879.0.0.

Reponse to #c2.  Filesapp gets keys and hostname from cicerone each time it connects, so I don't believe it would get stuck with old keys.

I believe that the issue is:
When the container is uninstalled, the mount at /media/fuse is not unmounted.

chronos@localhost / $ ll /media/fuse
ls: cannot access '/media/fuse/crostini_85df2af39f3d917452e3f926e641e58dcf9dbd5f_termina_penguin': Input/output error
total 0
drwxr-xr-x. 3 cros-disks cros-disks  60 Jul 16 10:04 .
drwxrwxrwt. 5 root       root       100 Jul 16 10:01 ..
d?????????? ? ?          ?            ?            ? crostini_85df2af39f3d917452e3f926e641e58dcf9dbd5f_termina_penguin

Then once the container is recreated, and we attempt to mount again, I am seeing this in the /var/log/messages which indicates that the system is not creating a new mount, since it believes it already has a mount to the specified remote destination:

2018-07-16T10:26:05.720572+10:00 INFO vm_cicerone[7745]: Startup of container penguin at IP 100.115.92.204 for VM termina completed.
2018-07-16T10:26:05.722379+10:00 INFO vm_concierge[7754]: Received GetContainerSshKeys request
2018-07-16T10:26:05.724068+10:00 WARNING disks[2029]: Path 'sshfs://joelhockey@penguin.termina.linux.test:' is already mounted to '/media/fuse/crostini_85df2af39f3d917452e3f926e641e58dcf9dbd5f_termina_penguin'
2018-07-16T10:26:07.197894+10:00 INFO VM(5)[7744]:  lxd_setup: Started container 'penguin'

If others are reproducing this error, some useful logs are:
tail -f /var/log/messages 
sudo dbus-monitor --system "interface=org.chromium.VmCicerone"

dats@, do we need to change the sshfs mounting to check for existing mounts and unmount them?  Or do we need to trigger the unmount somehow when the container stops or is uninstalled?

I will attempt to verify this issue using same version as original report.

It's a known problem with the way CrosDisks tracking mounts, but it's not high priority to fix right now as it's trivial to workaround: you can always ask to unmount first and then mounting will succeed. Also I'd say when crostini was uninstalled something should have trigger an unmount anyway.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92f7748fe20707f1e263ea047302ed1fd50f5a7a

commit 92f7748fe20707f1e263ea047302ed1fd50f5a7a
Author: Joel Hockey <joelhockey@chromium.org>
Date: Mon Jul 16 09:54:49 2018

CrOS FilesApp unmount with cros-disks when crostini sshfs container shutdown

In addition to removing the crostini volume with VolumeManager, also
call DiskMountManager::UnmountPath.

Bug:  859238 
Change-Id: I0b773896ed3048f0bc3c62dcb4835aa547438475
Reviewed-on: https://chromium-review.googlesource.com/1137967
Reviewed-by: Sam McNally <sammc@chromium.org>
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575213}
[modify] https://crrev.com/92f7748fe20707f1e263ea047302ed1fd50f5a7a/chrome/browser/chromeos/file_manager/volume_manager.cc

Verified on 10895.10.0, 69.0.3497.21 on kevin.