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)
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:
@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
.To avoid using a keyring, please refer to this wiki: https://github.com/Azure/azure-storage-azcopy/wiki/Improved-login-support-for-AzCopy-commands-(with-in-memory-secret-store)
@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)