yt-dlp: `--cookies-from-browser` errors when Chrome/chromium-based browser is open in Windows
DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE
- I understand that I will be blocked if I intentionally remove or skip any mandatory* field
Checklist
- I’m reporting a bug unrelated to a specific site
- I’ve verified that I’m running yt-dlp version 2023.03.04 (update instructions) or later (specify commit)
- I’ve checked that all provided URLs are playable in a browser with the same IP and same login details
- I’ve checked that all URLs and arguments with special characters are properly quoted or escaped
- I’ve searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
- I’ve read the guidelines for opening an issue
Provide a description that is worded well enough to be understood
cannot extract cookies from chrome when the chrome browser is open and after closing all the windows of chrome, it can run correctly i have no idea what is going wrong
Provide verbose output that clearly demonstrates the problem
- Run your yt-dlp command with -vU flag added (
yt-dlp -vU <your command line>) - If using API, add
'verbose': TruetoYoutubeDLparams instead - Copy the WHOLE output (starting with
[debug] Command-line config) and insert it below
Complete Verbose Output
C:\Users\Mechrevo>yt-dlp.exe -vU --newline -R 30 --proxy socks5://127.0.0.1:7890 -i -o "Z:\YouTube\%(upload_date)s %(title)s.%(ext)s" --ignore-config --hls-prefer-native --add-metadata --embed-thumbnail --sub-langs all,-live_chat,-danmaku,-jpn-JP --embed-subs --merge-output-format mp4 --live-from-start --cookies-from-browser chrome "https://www.youtube.com/watch?v=3DiKrPSmO5c"
[debug] Command-line config: ['-vU', '--newline', '-R', '30', '--proxy', 'socks5://127.0.0.1:7890', '-i', '-o', 'Z:\\YouTube\\%(upload_date)s %(title)s.%(ext)s', '--ignore-config', '--hls-prefer-native', '--add-metadata', '--embed-thumbnail', '--sub-langs', 'all,-live_chat,-danmaku,-jpn-JP', '--embed-subs', '--merge-output-format', 'mp4', '--live-from-start', '--cookies-from-browser', 'chrome', 'https://www.youtube.com/watch?v=3DiKrPSmO5c']
[debug] Encodings: locale cp936, fs utf-8, pref cp936, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version stable@2023.03.04 [392389b7d] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k 25 Mar 2021)
[debug] exe versions: ffmpeg 4.4-full_build-www.gyan.dev (setts), ffprobe 4.4-full_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.17, brotli-1.0.9, certifi-2022.12.07, mutagen-1.46.0, sqlite3-2.6.0, websockets-10.4
[Cookies] Extracting cookies from chrome
[debug] Extracting cookies from: "C:\Users\Mechrevo\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies"
[debug] Found local state file at "C:\Users\Mechrevo\AppData\Local\Google\Chrome\User Data\Local State" Traceback (most recent call last):
File "yt_dlp\__main__.py", line 17, in <module>
File "yt_dlp\__init__.py", line 967, in main
File "yt_dlp\__init__.py", line 927, in _real_main
File "yt_dlp\YoutubeDL.py", line 652, in __init__
File "yt_dlp\YoutubeDL.py", line 3827, in print_debug_header
File "yt_dlp\YoutubeDL.py", line 3871, in _setup_opener
File "yt_dlp\cookies.py", line 99, in load_cookies
File "yt_dlp\cookies.py", line 120, in extract_cookies_from_browser
File "yt_dlp\cookies.py", line 289, in _extract_chrome_cookies
File "yt_dlp\cookies.py", line 952, in _open_database_copy
File "shutil.py", line 418, in copy
File "shutil.py", line 264, in copyfile
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\Mechrevo\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Network\\Cookies'
[25380] Failed to execute script '__main__' due to unhandled exception!
C:\Users\Mechrevo>
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 25
- Comments: 70 (21 by maintainers)
Links to this issue
Commits related to this issue
- Use shadow copy to extract cookies when chrome is open Fixes #7271 — committed to csm10495/yt-dlp by csm10495 a year ago
As a temporary workaround, run
chrome.exewith:–disable-features=LockProfileCookieDatabase
Expect this flag to go away after a few more releases of Chrome.
That’s kind of offensive tbh. I was just providing a possible solution. This is open source code, people make recommendations, code changes, etc. it’s part of the culture.
I’m not sure why my suggestion would not instill confidence. I’m offended by that remark. It makes me think I shouldn’t share things that I think can help steer us towards a solution. I had been very excited to share that because it gives the possibility of fixing the issue for folks longer term.
Honestly it’s not a suggestion for someone who doesn’t know python. It’s a suggestion to other people at least somewhat familiar with parts of the yt-dlp source code.
I’m not sure why you then say it shouldn’t need to exist. None of us influenced the chromium behavior change here. We are where we are: trying to provide solutions.
Anyways, you don’t need
--cookies-from-browser. You can download the cookies.txt file then just pass those cookies via--cookies. Consider something like https://github.com/kairi003/Get-cookies.txt-LOCALLY to get that file.(edited to be useful)
This issue affects Windows versions of Chrome and some other chromium-based browsers such as Edge.
The workaround (at least for Chrome) is to launch
chrome.exewith the flag:--disable-features=LockProfileCookieDatabaseFor convenience, you can add it your desktop shortcut for Chrome. Right-click the shortcut, go into Properties, and change the executable path, e.g.:
"C:\Program Files\Chrome\chrome.exe" --disable-features=LockProfileCookieDatabaseI don’t have a solution but I have done some research that may be useful.
LockProfileCookieDatabasefeature results inSQLitePersistentCookieStore::enable_exclusive_accessbeing set?exclusive=truebeing added to the file URI passed to sqlite on Windows only sourceEXCLUSIVE locksection ofwinLock()I tried moving the Cookies database and creating a symlink and hardlink to it for chrome to use but
LockFileExfollows the links. It’s possible that if the database is placed on a filesystem that doesn’t support locking (like an old version of samba) then the locking won’t take effect but that isn’t a very practical solution.the shadow copy approach seems like a good way around the limitation on the yt-dlp side. I think admin will be required for any solution which makes many options available but most would be too invasive. One idea I had would be to create a separate tool that a user could use to start chrome and inject a DLL that makes
LockFileExdo nothing.The good news is that I don’t think Linux will be affected because mandatory locking with fcntl is opt-in and disabled by default source (see Mandatory locking section). WSL should also be unaffected because
LockFileExhopefully can’t be supported in WSLI can’t reproduce
I found the chromium commit-https://chromium.googlesource.com/chromium/src/+/03c1544d31014c04caace4145676c30586bd9612
I adapted the work of @csm10495 in to a yt-dlp plugin: https://github.com/seproDev/yt-dlp-ChromeCookieUnlock
Seems to be working well for me. Use at your own risk.
And I guess I spoke too soon-ish. This project: https://github.com/thewh1teagle/rookie came up with a way to do it without admin. It cheats a bit, it actually kills the process in chrome that holds the lock to the file… thus releasing the lock… but hey chrome, just restarts it when needed and it works out fine.
I’ve replicated it in a pure-python gist here: https://gist.github.com/csm10495/e89e660ffee0030e8ef410b793ad6a7e… using that logic cookies can be fetched even while Chrome is running, without admin.
Up! Today noticed that yt-dlp doesn’t read cookies from browser, when browser is open. yt-dlp v.2023.07.06 edge v.117.0.2045.31
Not sure what we can really do if this is an intentional change to chromium (which could trickle downstream to Brave et al). We can’t tell people to downgrade their browsers.
Firefox for all?
For some reason, not sure if related but the --disable-features=LockProfileCookieDatabase seemed to slow down and cause my chrome to hog more memory. Might be a no brainer, but worked better than the Chrome solution for me is to just get them from Firefox instead.
–cookies-from-browser firefox
Maybe it is of interest, but the official Microsoft Bing Wallpaper app ran into similar issues and they updated the Bing Wallpaper app to adapt to the changes in Chromium/Edge (enablement of LockProfileCookieDatabase), see: https://twitter.com/ericlaw/status/1719368738514882581
(another small point: Also it works fine for all browsers on Linux or Mac, only Windows is affected)
I have switched to firefox, so much easier and no issues with decrypting cookies:
yt-dlp --cookies-from-browser firefox:~/snap/firefox/common/.mozilla/firefox/ ...@ForsakenRei for that use case you may want to use
yt-dlp --cookies-from-browser <mybrowser> --cookies cookies.txt(no other arguments) (while the browser is closed if you are on windows) which will cause yt-dlp to write out the cookies to that text file, then you can use that file as your cookie storage withyt-dlp --cookies cookies.txt ...(but be aware of the security implications of having your cookies lying around in a text file and be careful where you put it)
now edit your reply with correct link
If you suspect your computer had been compromised, just invalidade the cookie(s) by logging out of the respective accounts. Easy to do. When you log in again, it will generate new cookies.
mbway is saying that yt-dlp should do this, so that users are immediately made aware of the potential issue and the workaround.
Works fine with non-chromium browsers
This is the plan
I’ve closed the PR for shadow copying to prevent it getting more stale. In the future if the team wants, i’ve moved the shadow copy functionality to https://github.com/csm10495/shadowcopy. They can import it and shadow copy, etc.
@ofek https://github.com/seproDev/yt-dlp-ChromeCookieUnlock/pull/1
then after PR is merged you can:
What’s the point of such security? Clowns from chrome never disappoint
我也遇到了这个情况，目前找不到解决方案 我使用的是Windows11和edge浏览器 有人知道如何解决请帮助我
Thank you. Yeah it’s quite dangerous to put my cookies as a plain file even though I only extracted cookies for YouTube, hopefully we will have a better solution later.
Opened a PR to allow this to work at least when the user is admin via a shadow copy. (https://github.com/yt-dlp/yt-dlp/pull/7290)