stop!!!!!

Yes, there is the DeviceEphemeralUsersEnabled policy which would erase local user data when users logout, however this prevents tracking which users were using particular devices, information which is helpful, especially in multi-user environments where damage to devices is more frequent.

Present behavior of removing oldest unused profiles is clunky, the Storage warning still pops up, giving users the impression that some action needs to be taken on their part in order to continue using the device.  Often times larger files will fail to download due to there not being enough locally available space (possibly a separate bug report).

DeviceEphemeralUsersEnabled also imposes a 1GB limit per user if I understand correctly. This would cause additional problems.

re Comment 3 - that is my understanding as well. We've had issues with this when users wanted to download a 2GB file.  Even with the setting to save files directly to Google Drive, larger files were unable to be saved.  At the time I was attributing it to the low amount of available hard drive space, but in retrospect it was likely due to this limitation.

I was just notified by Google Support on a ticket for a similar issue that there is presently an Undocumented feature in Chrome OS that any profile that has not been logged into for 90 days is deleted from the device.  It's good that it's there (would be nice to be documented in a public facing manner).  We're wanting to be able to set this administratively via cpanel policy.

Assigning to David for prioritization.

> Yes, there is the DeviceEphemeralUsersEnabled policy which would erase local
> user data when users logout, however this prevents tracking which users were
> using particular devices,

That's surprising to me.  Are you identifying recent users by looking at the user pods on the login screen or via the management console?

From within the Admin Console devices page.  The write event to the device
activity is associated with the logout event, which doesn't tell who the
current user is (problem 1 with this logic) and if a user preforms a hard
reset, or if the battery dies the recent user is never updated (problem 2).
There is a separate feature request asking to associate the recent user
information with login rather than logout and include an actual timestamp
rather than an unassociated session duration, which is really not very
helpful.

Very interesting, thanks.  I'll leave that to David.

PLEASE.  This is a major problem ongoing with us for years.  Anyone using shared lab/cart chromebooks runs into this issue unless erase local data is on.  We do not use that because of the tracking capabilities that are lost, as mentioned in this article.   Currently what we resort to is turning on erase local data for a couple weeks whenever we start hearing of these issues and then turning it back off to regain tracking.

Adding eng and PM folks. Assigning to Max as this is on the EDU critical journey.

"Present behavior of removing oldest unused profiles is clunky, the Storage warning still pops up, giving users the impression that some action needs to be taken on their part in order to continue using the device.  Often times larger files will fail to download due to there not being enough locally available space (possibly a separate bug report)."


Any idea of where we set the bar to auto-remove old profiles? Can't we just set a higher bar e.g. start deleting when we have 1GB left instead of when we have 50MB left?

Adding people who know more about the current delete behavior

The intended behavior was that managed devices with multiple users left should not show a warning.  Instead they should just start clearing LRU profiles. +mitsuji can you confirm that is actually happening?

I can say for sure that our managed devices definitely show the message. Furthermore, not enough space is cleared out whenever space is freed as some applications (screencastify, for example) end up failing to save larger files.  

Possible solutions include a policy as mentioned by others to clear out anything older than X days (best option), enable all data to be erased without losing tracking capabilities (and without the 1gb profile size limit it also imposes), or to, at minimum, do much more agressive automatic cleaning. 

I merged into the other bug because if the bug is fixed, there is no need for such a policy. We should simply fix the bug.