Azure Managed Service Identity: Failed to acquire tokens after 12 times - azure-active-directory

Question

I have a VM with a system-assigned managed service identitiy. I gave it permission to pull images from the Azure container registry. I followed this tutorial.
I worked fine yesterday. But when wanting to pull a new image, it said to re-authenticate. This is where it fails. When I either execute one of the following I'm getting errors, stating that the token acquisition failed.
Am I doing something wrong?
az login --identity
az acr login --name MYREGISTRY
MSI: Failed to acquire tokens after 12 times
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 206, in invoke
cmd_result = self.invocation.execute(args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 328, in execute
raise ex
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 386, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 379, in _run_job
six.reraise(*sys.exc_info())
File "/opt/az/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 356, in _run_job
result = cmd_copy(params)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 171, in __call__
return self.handler(*args, **kwargs)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/__init__.py", line 441, in default_command_handler
return op(**command_args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/profile/custom.py", line 111, in login
return profile.find_subscriptions_in_vm_with_msi(username)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 297, in find_subscriptions_in_vm_with_msi
msi_creds = MSIAuthentication(resource=resource)
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 576, in __init__
self.set_token()
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 584, in set_token
token_entry = self._vm_msi.get_token(self.resource)
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 632, in get_token
token_entry = self._retrieve_token_from_imds_with_retry(resource)
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 674, in _retrieve_token_from_imds_with_retry
raise TimeoutError('MSI: Failed to acquire tokens after {} times'.format(max_retry))
TimeoutError: MSI: Failed to acquire tokens after 12 times

Answer 1

There is the explanation that what you do follow the document.
az vm identity assign -g myResourceGroup -n myDockerVM.
This CLI command means you enable the VM system MSI. See az vm identity.
az role assignment create --assignee '0a6b28fd-*********' --scope '/subscriptions/{subscription-id}/resourceGroups/{your-resource-group}/providers/Microsoft.ContainerRegistry/registries/{acr-name}' --role reader
This CLI command means you assign the VM Reader permission to access the ACR with the VM system MSI.
az login --identity
This CLI command means that you log in using a VM's system assigned identity. The permission dependant on the assignee with the VM. So that you can run CLI command with the VM permission.
az acr login --name ManiTempRegistry
This CLI command means you log in the ACR with the current user. In this issue, it means you log in the ACR with the VM system MSI with Reader permission.
All the above steps finished, then you can just pull the docker image from the ACR as a Reader. And the token is stored in the file ~/.docker/config.json. And the file will show like this:
So if the token is not expired, you do not need to log in again. So you can check if the token is alright. Any more question you can give me the message.

Answer 2

Accepted answer did not work for me, but stopping and then starting the VM again solved the issue. Mind you that a reboot has not worked; had to Stop and then Start from the Azure web interface i.e. deallocation and reallocation of the VM. Looks like a glitch in Azure VM allocation.