Here is another active thread on CBC
https://productforums.google.com/forum/#!topic/chromebook-central/2iz9jPYZl90

alemate@ can you look into this ASAP?

I have experienced this issue now as well, similar to the CBC reports (which is how I found this bug report). 

I use one Supervised User account on two separate Chromebooks (different brands) at home for two of my children. They are both logged in simultaneously to the Supervised User account on each of their Chromebooks at all times. This has allowed me to easily whitelist sites that are then available to both Chromebooks.

We have been using this setup for about a year now and it has worked great. I tell everyone I meet how easy it is to manage my kid's internet access this way. Suddenly around Tuesday of this week (11-8-16), one of my kid's Chromebooks showed the Supervised User account disabled and would no longer allow login to it. There is a text dialog that says "Supervised user may have been deleted or disabled by the manager".

Version 53.0.2785.154 (64-bit)
Platform 8530.96.0 (Official Build) stable-channel gnawty
Firmware Google_Gnawty.5216.239.34

Acer CB3-111 series 

Updated affected Chromebook to the following with no change:

Version 54.0.2840.93 (64-bit)
Platform 8743.83.0 (Official Build) stable-channel gnawty
Firmware Google_Gnawty.5216.239.34

Other Chromebook with same Supervised User is not affected and logs in normally.

alemate@ is gardening, xdai@ could you take a look?

Let me know if there are any logs or technical details that would help. I've created a completely new supervised user as a workaround so that we can leave the old profile in place for troubleshooting. I'm not familiar with the inner workings of Chromium, but am a software engineer by trade and can follow technical directions comfortably if there anything you need me to do. If you email this address I will see it much faster as a side note.

Also, the user seems fine on the Supervised Users -> Manage screen. Possibly a bad state in the local profile of that one account on the Chromebook affected. 

-Daniel

Our daughters each have an Acer Chromebook 11 with Google Chrome OS (version 54.0.2840.93) that they received for Christmas 2015. I set up Supervised Users for each of them at that time and suddenly neither one of them can log in to their Chromebook and get the message "This supervised user may have been deleted or disabled by the manger. Please contact the manager if you would like to continue signing in as this user." I am not aware of making any changes to their accounts especially since it has been quite awhile since I've even been on the "manage" site.

After seeing these posts, I'm curious if something didn't happen on your end since it's not an isolated incident.

Looking forward to a resolution other than deleting and recreating the users and losing all of their permissions and blocks. Thank you.

We also are experiencing this - 2 kids accounts are locked out on a Chromebook.

We have just experienced this same issue with a supervised account that has been in use for over a year.  It was fine one night and the next morning it gave the deleted or disabled message.  I hope this account can be recovered because he has a bunch of saved links and information.  Please let us know if any progress has been made with this issue and if this can be recovered.

Same issue. Applied the latest update and now my son cant log in.

Happened to me around the 8th, One Google account and two Supervised users, one with full access and one limited.  Neither Supervised user could be logged into, but I could "manage" them.  A couple of days after original problem, I created a new full access user since simple to do.  Did not want to keep letting my son use full access account, so last night I created another limited user account for him.  While Managing the original limited user, I did Screen Captures of the listing of sites I had approved on that original limited user.  I then used these images as a reference to reenter the approved sites on the new limited user.  Then deleted original supervised user.  Was there some way to import the approved sites into the new user to make process easier?


Add a comment 

Just now happened to our Chromebook (Samsung). Chromebook updated, and now the Supervised user is 'deleted' or 'disabled' As this is used for schoolwork, it has become serious. I can always create a new one, but we do not want to lose all the work done over the past year and a half.

My daughter's chromebook developed this problem yesterday 11/12. She was using it as normally as a supervised user, and then it froze on her and she restarted it.  Since then it reports that her account has been deleted or disabled.

achuith@ can you dig into this one?  I know you're also working on getting the new tests in place but this looks really urgent.

Alex - do you have any ideas about what's going on here?

My boys' both have Acer cb3-111 chromebooks, working fine as supervised users since December 2005. I believe that we got the supervised user is "deleted or disabled" after the update to 54.0.2840.93, firmware Google_Gnawty.5216.239.34

My daughter's chromebook hit this same issue.  I was at least able to restore her access by doing:

1) log into the chromebook as myself
2) go to settings:manage other users
3) remove the broken account from the list
4) uncheck "only allow users from the list"
5) log out
6) click "add supervised user"
7) click on the link in the bottom right for importing existing supervised user
8) choose my daughter's same account that already existed

This approach at least preserves the existing supervised user account, with all its settings a whitelisted web sites, etc.

The [minor] disadvantage of this approach is that all her bookmarks were lost in the process, and had to be recreated.

Same issue on Acer cb3-111.  Started in the last few days.  Currently 
Version 54.0.2840.93 (64-bit)
Platform 8743.83.0 (Official Build) stable-channel gnawty
Firmware Google_Gnawty.5216.239.34

Clearly there is a bug in the software that has disabled lots of supervised user accounts.  My two daughters each have chromebooks - the one that uses her's a lot is fine, the other one who has only started to use it again yesterday is now locked out (was able to log in once).  So, it looks like a bug in the older software that allows one login and then locks the user.

Please sort this ASAP, as I have a very unhappy daughter plus this issue was initially reported 3 weeks ago! 

An addition that I've not read yet. The owner account on our sons CB was in a similar state though it didn't indicate the same error message. Son's SU account was experiencing this bug so I used the owner account which wouldn't let me logo  either. I used the guest feature and was able to navigate to the google account associated to the owner of the CB. Odd... I fiddled around bouncing between guest and owner and finally the CB asked me for my old password if I wanted to continue to logon with this account (owner)... what the heck, I entered the old password and sure enough, I was able to access the owner account on the CB. I rebooted to test and was still able to logon. I've updated Chrome OS to no avail, the SU account is still "deleted or disabled". Not interested in others suggestions of removal, creation of new and importing if that messes with book marks... what else does it mess with/lose?

Hello.  So far I am only seeing reports of the problem and that people are deleting or recreating the account but losing bookmarks and passwords.  I know it is being worked on but this seems to be a pretty big issue when your user base can't log into an account suddenly for no apparent reason.  I wish they would at least provide some advice on what to do with the locked account.  I can create a new temporary account but how should we preserve the locked account?  What should we do in the meantime to allow use and hopefully eventually restore the locked account?

Hi all, we are aware of how painful this bug is and are indeed working towards a fix. Until we know exactly what that fix entails it's hard to provide further advice, but thank you all for the detailed information and we will continue to update this bug as we make progress.

#27, thank you for the update. We continue to receive reports on CBC from frustrated parents.

Just a heads up, we are nearing 55 stable and this is marked as a blocker, if we can get a fix in the next two days we can make the targeted RC, if not we may have to punt or delay. 

As this appears to be live in the field already on stable (starting in 53?), we may not want to block the stable update on it unless we believe the 55 stable will make it worse. 

David, Danny - I need some help from QA in getting a repo.

As I understand it, people are unable to log into their supervised user accounts, which were created sometime before, and these seem to suddenly stop working (login fails). 

It looks like a supervised account created at some point in the past will fail to login with chrome from the present.

I thought this started in M54 - which branched around Jul 1. But a supervised account created with the chrome of Jul 1 works with chrome from TOT.

I saw some reports in the forums from M53 users who were seeing this problem. M53 branched May 19. But a supervised account created with chrome of May19 also works with TOT chrome.

Currently I'm simply creating a supervised account and logging in, but it's possible there's a more complex sequence that triggers this problem. And it's also possible that this doesn't repo reliably. I'm also doing all of this on chrome for chromeos running on linux, and there's a small possibility that there's some chromeos system bug which I wouldn't see in this configuration. It looks like these supervised accounts are sync'd, and it's possible there's some incompatibility bug in sync as well.

I'm going to look at CLs relating to logging in supervised users, but it's a shot in the dark without a good repo.

If it was ALL supervised users, I might expect more bug reports.  I
expect it is just SOME - the key is to figure out WHICH and WHY.

The code path that's triggering this error message is here:
https://cs.chromium.org/chromium/src/ui/login/account_picker/user_pod_row.js?l=1454

Qiang, Alex - did anything change with legacy supervised users in the last 6 or so months?

My observation (not replicated, as I can't repro given that it is blocked) was that our chromebook was put to sleep with the supervised user logged in.  While the supervised user was logged in and the machine was in sleep, chrome was updated.

However, I created two supervised users ~11-12 months ago (I'm not sure which release that corresponds with), and both suffer from the lockout problem.  Implies that it wasn't the user specifically, but perhaps the sleep state?

Is there something unique that happens when chrome is updated while a supervised user is logged in while sleeping?

Legacy supervised users have been around for a long time, they predate this renaming CL from 21 months ago: https://codereview.chromium.org/960403003/

Nikita/Tatiana, do you have any ideas about what could be triggering this warning?

Johnny - chrome is shut down, all users are logged off before an update is applied.

Since this already exists in the field, we don't need to block 55 stable on it.

However given the severity if we can find a fix for this we can still merge it into 55 for a later stable push.

Hi Chrome team. Here's a few details from my experience that might help you reproduce the bug. Just for reference, I setup my 89 year old mother as a supervised user on a Chromebox about a year ago to keep her out of trouble ;-) This after the fake Windows repair people called her and convinced her to setup LogMeIn for them on her PC. So, I love the Chromebox solution. Y'all rock.  Ok, details:

> Our managing user and supervised user accounts were both created in Sept 2015.
> I believe the problem started happening for her on or around Nov 11th of this year. 
> In looking at her activity reports, it appears she was inactive from Nov 4th until I fixed the problem, on the 13th I think. 
> I noticed a few other people also reported this problem followed a period of inactivity.  The problem appeared after a vacation, etc. 
>  My managing user had been inactive for several (probably more than 6) months.
>  There was a period this spring when my mom was ill and didn't use the Chromebox for a couple of months, but it worked fine when when she returned home from the hospital. So it's not simply the inactivity that triggers it; there must be something else to it.
>  I was able to login to Google from my Windows machine using the managing account, and view the supervised account, without a problem.   

That's all I can think of, but let me know if there is any other info I can provide that might be of help. (I'm a developer, so I get it).  

Good Luck!
Joanne

We tried to repro it internally but couldn't.

We tried creating the supervised users in M53 and using for a bit on each milestone before updating to M54, M55 and M56.

Thanks for taking a look, David.

Is there a way for one of us who has a corrupted profile to provide it to
you?

I went back and checked, and it turns out I was wrong in comment #34.

I have two supervised users.  The one that was logged in during the update is inaccessible.  The one that was not logged in is functioning fine.

I just tried to add a new supervised user, got a warning that it was "taking too long"... when I cancelled, I was returned to the main sign in screen, but the wallpaper associated with *my* user was changed to the system default.  Strange, and repeatable.

(Not a chrome developer, but engineer here... happy to grab some logs/info/etc. as needed.)

Thanks for working on this gang.

Achuith, I wonder whether this is a server-side issue with the supervised user's refresh token (i.e. it has been invalidated or something).

I am also having this issue with a supervised user on an Acer chromebook within the last two weeks.  Any updates on a fix?

I am having the same problem, both my daughters have a supervised user accounts that are experiencing the same issue as mentioned above, after talking with Asus and then google I was told to delete and reinstall a new operating system.  I just completed the installation and it is still not working. I am beyond frustrated at this point.

My family is ready to abandon Chromebook at this point.

There's a good chance this CL will work:
https://codereview.chromium.org/2563573002/

To recap a discussion with Alex:

ChromeOS uses legacy supervised accounts, not child accounts. Child accounts (aka unicorn) was never enabled on ChromeOS.

Legacy supervised accounts are not GAIA entities (so GAIA id is not set for these users) - there is some metadata attached to the parent account that is sync'd but these are not full-fledged accounts. Thus it isn't possible to authenticate these online.

The symptom described in this bug pops up here:
https://cs.chromium.org/chromium/src/ui/login/account_picker/user_pod_row.js?l=1459

We post this message: 
"Supervised user may have been deleted or disabled by the manager"

We do this in response to an attempt to authenticate online. The code that checks for online authentication of supervised users is here:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/screens/user_selection_screen.cc?l=252-254

Here we try to force an online auth when the oauth token becomes invalid. 

I believe that the oauth token is inherited from the parent user (I haven't dug into this), and when it eventually becomes invalid, the supervised user account is effectively locked out, and we start showing this error message.

My CL is pretty small, and should be safe to merge into M56 and M55.

I wasn't able to invalidate the oauth2 token by changing the password on the parent account or by explicitly revoking access on accounts.google.com on the device, so I haven't really been able to test this CL.

+nepper

Achuith, your belief about OAuth tokens being inherited from the custodian is correct :) One thing to note though is that a lot of the functionality of supervised users  (syncing settings and auditing browsing history) depends on the OAuth token being valid, so the supervised user would now be able to use the device without that, which might not be what the custodian intends.

Also, is there any confidential information in this bug requiring us to restrict it? A lot of external users are reporting this, so they won't be able to see updates. If necessary, we can file a second bug that is RV-G.

Oops, restored public access. Sorry about the mix-up folks!

Bernhard - do you know how/where this oauth token is refreshed? Because the ideal solution would be to refresh this token for the supervised user when the parent refreshes theirs.

The initial refresh token for the supervised user is fetched with SupervisedUserRefreshTokenFetcher (chrome/browser/supervised_user/legacy/supervised_user_refresh_token_fetcher.h). The tricky part is that we do that from the custodian user and then stuff the token into the supervised user's profile during creation, which might be more difficult to do at a later point.

For the purposes of testing - how does one go about revoking such a token? I'd like to see what happens with my patch.

Breno probably knows the most about revoking tokens :)

Is this continuing to happen anew or was it a one-time occurrence before mid-November (that disabled the accounts permanently in the device).

There are a couple of forum posts, but they all seem to be around Oct-Nov timeframe. Was there an event around this time that invalidated oath2 tokens?

There's an issue where GAIA auth errors spiked mid October: https://bugs.chromium.org/p/chromium/issues/detail?id=672690

There's an issue where GAIA auth errors spiked mid October: https://bugs.chromium.org/p/chromium/issues/detail?id=672690

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

commit 9b57da68302423b74d098c015c97dfe7c9c94ba6
Author: achuith <achuith@chromium.org>
Date: Thu Dec 15 08:51:24 2016

Allow legacy supervised users to login with invalid oath tokens.

Currently we force online login for legacy supervised users when the oauth
token becomes invalid. However there is no online login for legacy supervised
users - we just print a cryptic error message, and there is no way to refresh
this oauth token, so the account is effectively locked.

BUG= chromium:659788 
TEST=manual

Review-Url: https://codereview.chromium.org/2563573002
Cr-Commit-Position: refs/heads/master@{#438786}

[modify] https://crrev.com/9b57da68302423b74d098c015c97dfe7c9c94ba6/chrome/browser/chromeos/login/screens/user_selection_screen.cc

This is marked as fixed - when can we expect an update to push?

Discussed with Albert, We'll merge this after some bake time on M56 beta 

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

commit b1cdc3f6a193cb841dff5dfbb15bd73342665606
Author: Alexander Alekseev <alemate@chromium.org>
Date: Thu Dec 15 22:42:45 2016

Allow legacy supervised users to login with invalid oath tokens.

Currently we force online login for legacy supervised users when the oauth
token becomes invalid. However there is no online login for legacy supervised
users - we just print a cryptic error message, and there is no way to refresh
this oauth token, so the account is effectively locked.

BUG= chromium:659788 
TEST=manual

Review-Url: https://codereview.chromium.org/2563573002
Cr-Commit-Position: refs/heads/master@{#438786}
(cherry picked from commit 9b57da68302423b74d098c015c97dfe7c9c94ba6)

Review-Url: https://codereview.chromium.org/2583693002 .
Cr-Commit-Position: refs/branch-heads/2924@{#519}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/b1cdc3f6a193cb841dff5dfbb15bd73342665606/chrome/browser/chromeos/login/screens/user_selection_screen.cc

[Automated comment] There appears to be on-going work (i.e. bugroid changes), needs manual review.

[Automated comment] There appears to be on-going work (i.e. bugroid changes), needs manual review.

Experiencing this after updating

I have been going crazy with this problem for the past two and a half years.

I tried a long time ago to communicate with anyone to explain that this was clearly a bug, but no one responded.  Yes, yes. I know. You're getting millions of messages every day.

But for 2 and a half years, you haven't been able to find a solution to this problem?  What's worrying me is that comment 72 is saying that they experienced this AFTER updating!

PLEASE HELP!!! I'm dealing with 40+ computers experiencing this CONTINUOUSLY ALL THE TIME! 

Well, I AM using it as it is supposed to be used, and I have the same question.  Progress? 

Those who are still experiencing this after updating, what version are you running now, and were the affected supervised users created before or after updating?

I still experienced the problem after the latest update.  My supervised users were created well before updating (a few years before).  I don't have access to my Chromebook at this moment, but I have been checking frequently for updates in hopes this issue would be resolved, so I know it is on the latest stable release.

I believe this fix made it into 56, not 55, so it has not yet hit stable but should soon.

The fix made it into 56 and I was able to access my kids/supervised user accounts again.