azure-storage-azcopy: azcopy login/logout fails

Which version of the AzCopy was used?

10.1.2

Note: The version is visible when running AzCopy without any argument

Which platform are you using? (ex: Windows, Mac, Linux)

Ubuntu 16.04

What command did you run?

$ azcopy login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code xxxxxxx to authenticate.
INFO: Login succeeded.

$ azcopy logout
Error: failed to perform logout command, no cached token found for current user
Usage:
  azcopy logout [flags]

Flags:
  -h, --help   help for logout

Global Flags:
      --output-type string   format of the command's output, the choices include: text, json. (default "text")


failed to perform logout command, no cached token found for current user 
Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.

What problem was encountered?

See above: interactive AD login seems to succeed. But if I try to logout immediately, the logout fails. All other commands (e.g., azcopy copy) also fail, indicating that the login did not actually succeed.

On my other (Ubuntu 18.04, not sure if that’s relevant) machine, this all just works.

Both machines are on my desk.

How can we reproduce the problem in the simplest way?

Please see above. The problem is that the problem is only reproducible on one of my machines, so I’m not sure you will be able to repro.

Have you found a mitigation/solution?

Yes, I could use a SAS token instead.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 20 (7 by maintainers)

Most upvoted comments

I suspect the login has also failed.

To check, can you login, then do keyctl show

You should see an AzCopy key (with a distinctive AzCopy-related name) in the session key ring. I suspect you will see that on your other Ubuntu, but not on the failing one.

If so, it sounds similar to an issue we saw on SUSE 12. There, the issue seem to be that the session key ring was not propagated/shared in the expected way. I.e. not according to (our interpretation of) the keyctl documentation. The workaround there was simply to switch to a named session keyring, instead of the default. To do that, run keyctl session workaroundSession then use AzCopy as normal. (the session name can be whatever you like, I just called it “workaroundSession” in this example).

I’d suggest you try that, and let us know if it works for you.

For debian system adding this at beginning of the script makes the script work: /bin/keyctl new_session

I got it working with the oauth token:

keyctl new_session
sleep 1
azcopy login --identity --identity-resource-id ${identity_id}
keyctl show #user oauth token displayed
azcopy cp '${blob_endpoint}/artifact.tar' '/opt/artifact.tar'

@JohnRusk On Ubuntu 22.04 and years later, but wanted to say thank you for the workaround! 🎉 – I’ve struggled for a long time to get azcopy login to work (given it says “Login successful”) and in spite of many closed issues reporting the same underlying problem which made me think it’s been fixed. Thanks!

@zezha-msft Thanks. This should be in the CLI help page azcopy login -h.

@AddisonG could you please open a new issue with more details? E.g. which flavor of Linux, which version, etc.

Please also consider bypassing the keyring: https://github.com/Azure/azure-storage-azcopy/wiki/Improved-login-support-for-AzCopy-commands-(with-in-memory-secret-store)