Zone.Identifier Files when downloading from Windows to WSL file structure

[ameya-jain]

When downloading a file from an online source lets say this image or a zip folder and directly saving it to the WSL file structure using the Microsoft Edge 'save as' option ( I have turned off the default download location so edge asks me every time where I should save something downloaded), when the download is complete I see these Zone Identifier files.

I read about a similar #4609 issue and from what I understand is that these files shouldn't be downloaded or should be removed after download.

My Ubuntu specifications :

My windows :

[YAMLcase]

Is there a workaround for this?

[ameya-jain]

Is there a workaround for this?

I usually use VS Code and is connected to my WSL. Instead of directly downloading the files from the browser to WSL, I download to windows, open the WSL folder in VS Code and then drag and drop the files from windows to VS Code. This seems to not bring the Zone.Identifier files.

[Volper212]

I download to windows, open the WSL folder in VS Code and then drag and drop the files from windows to VS Code.

That's another step though, I think deleting the zone identifier file is less work since you only have to delete it at the end of your work, not every time you download. You can technically even keep it and just add it to .gitignore but it would be cool if you could disable generating the file completely, or just not generate it if it's empty anyway

[rehanhaider]

I can confirm this issue still exists on Windows 11, even though it was supposed to be fixed. Steps to reproduce are

1. Open any webpage and download an image, similar to this sample image
2. In the "Save As" dialogue, choose "Linux -> Ubuntu" and browse to folder of choice, and save
3. Creates a file with name <download-file-name>:Zone.Identifier

[JacobDB]

I'm also still seeing this in Windows 11, any time I download a file and copy it over to WSL via File Explorer, along comes a :Zone.Identifier.

[Kai-Richardson]

As the filer of the original issue, I can confirm this is still not fixed for either Windows 10 or Windows 11.
Exact same reproduction steps I outlined here still work:

1. Navigate to an image url.
2. Right click and Save Image As
3. Choose location on my Windows NTFS C: Drive, such as C:\Users\zekai\Desktop
4. Drag (Click and hold) or copy/paste (CTRL+C & CTRL+V) PNG file to a WSL filespace, such as \\wsl$\Ubuntu\home\cassini\github
5. Nothing appears at first, but click the refresh button on explorer.exe in the top right.
6. Notice new Zone.Identifier file.

[MattDirty]

Problem arised for me when I went from my Windows 10 Pro N to a clean install of Windows 11 Pro N. I thought the issue was me switching my daily driving wsl distro from Ubuntu to Manjaro but after installing Ubuntu, the problem is also there. So the culprit must be my new Win11 install.

I could spin up my old Win10 to see what were my config (I'm pretty sure Windows Defender was deactivated). I had to activate TPM for Win11, other than that my hardware stayed the same.

Let me know if replugging my Win10 drive to test and gather the config differences is something that could help.

Side note: ZoneIdentifier files are also created when copying from Manjaro to Ubuntu via explorer.exe.

[mattwelke]

Having this problem in Windows 10 Pro. Copied a file from one File Explorer window to another, where the first one was my Downloads directory on the Windows side and the second one was a WSL 2 directory.

I was able to delete the file via VS Code's GUI after I closed all my File Explorer windows (before closing them, it said "this file is in use" etc). I wasn't able to delete the file from the WSL 2 terminal. It was as if the WSL 2 terminal couldn't target the file using the rm command. And rm *Identifier said an error like "not a file".

[dtromans]

It's funny how the original issue was closed as "fixed" when the supposed fix never landed outside of insider/preview builds.

[saurav-codes]

this issue still exists in windows 11. please fix this ASAP

[brunocantuaria]

Still happens here as well, on Windows 11

[ferrouswheel]

The Zone.Identifier file has host and referer urls, which can contain query string access tokens. While any decent web service should expire tokens, potentially having plaintext credentials lying around in files is... a little dodgy.

Would be nice for this to be resolved.

[MatthewMierzwa]

This issue also happens on my Win 10 build 19042 & WSL 2 running Ubuntu.

[minh14496]

The issue still persists on Window 11 21H2.

[RichIsOnRails]

Can confirm, happens on:

Edition Windows 11 Pro
Version 21H2
OS build 22000.493
Experience Windows Feature Experience Pack 1000.22000.493.0

Downloading a file from Microsoft Edge directly to the WSL location or copying it from Downloads does the same thing for me.

[vietaalto]

Confirm. Happen to me with Windows 10 Pro and WSL2

[georgej1144]

Can confirm on

• Windows 10 Home
• Version 21H1
• OS Build 19044.1526 and 19044.1566

Only way I've found to move/copy files to WSL without getting Zone.Identifiers is my moving/copying from within WSL (cp/mv/etc).

[soundnotation]

Can confirm the issue on:

• Windows 10 Pro
  • Version 21H1 (Build 19043.1526)
• WSL Ubuntu release: 20.04
  • cat /proc/version: Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020

[vitsafarik]

Can confirm the issue on:

Windows 11 Pro
Version 21H1 (22000.527)

WSL Ubuntu release: 20.04
cat /proc/version: Linux version 5.10.16.3-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Fri Apr 2 22:23:49 UTC 2021

[Jorggyh]

Well, the same thing happened to me, saved in windows, cut and pasted in a linux folder, and out of curiosity I went to research what it was and ended up here, so.. it still happens

Windows 11 Home Single Language
Version 21H2 Comp. 22000.556
Ubuntu 20.04

[hichemfantar]

Present in Windows 10 21H1 with WSL2

[HakuOTR]

Can confirm the issue on:

• Windows 10 Pro
• Version 21H1 (Build 22000.556)
• WSL Ubuntu release: 20.04
• cat/proc/version:

Linux version 5.10.60.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Aug 25 23:20:18 UTC 2021

[AdmiralCode]

@HakuOTR I would just give it some time. Hopefully they will fix it soon. We ended up going with the (M1 based, this year) Macbook Pro again. I could not even attempt to justify anything else, considering I have to support my developers. WSL is still proving to be far too immature. It is getting close, however. Maybe one day.

Please note that the majority of my folks would love to run Windows with a WSL2 dev environment, but it has to work, right now the list of bugs is long, and the patience is short. We still don't have systemd support, for example, and that isn't even remotely an issue that is a blocker for us. The blockers?

1. No ability to autostart background services unless Windows is involved in some oddball hack.
2. Unexpected filesystem changes that have to be filtered out
3. Enterprise support for WSL? Seems nonexistent? We spend well over 6 figures (like, exponentially, though I won't disclose figures thanks to NDA) with Microsoft, how is it that WSL/WSL2 has no support? Or did our team miss something?

I wish everyone the best of luck.

[dospuntocero]

you can sudo find . -name "*:Zone.Identifier" -type f -delete
worst workaround, but works.

[JoshuaJarman]

2022-05-25 Win11 Pro Insiders 25120rs_prerelease.220513-1246

Problem still persists. 😢 such a pita to have to delete 2 files for every 1 file copied.

[KristianLake]

this issue causes files that if are uploaded by accident can cause builds to fail in CI/CD

[sebday]

Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder

Open gpedit.msc

• Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
• Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok

[UnknownMasterCoder]

Problem persists and seriously is disgusting this kind of bugs happening in WSL. Have to create an alias to delete fast those Zone.Identifier when I'm copying assents to my WSL, but its time workflow and most important is unnecesary work.

This needs to be fixed

[archon810]

Turning off "preserve zone information in file attachment" seems to have stopped the zone.Identifer files being created when I copy-paste into a WSL folder

Open gpedit.msc

• Open User Configuration>Administratives Templates>Windows Components>Attachment Manager.
• Double-click on "Do not preserve zone information in file attachment" and set it to enabled, then press ok

I've done this but WSL is still creating the Zone.Identifier files.

[nilsonsales]

How difficult is it for Microsoft to address this issue? It's been more than 4 years...

[Youjin1985]

How difficult is it for Microsoft to address this issue? It's been more than 4 years...

They don't care.
Oh, and today I got those f*ng files after simple copypastiing to WSL folder, no downloading

[maciejk-code]

@darylknight Count me in for the beach house 👯

[savely-krasovsky]

In my opinion it is not the problem of Windows. Windows creates those files for every file downloaded from the internet by default using NTFS's Alternate Date Stream, so you don't see it in Windows native directories (but they are still there!). ext4 used by WSL doesn't support it, so it just creates it using usual API. If you don't like it, turn the feature off completely using Group Policy above or just switch to Linux.

[L1Q]

or just switch to Linux

This was my solution, can recommend. The .vhdx image can be mounted pretty easily with nbd on linux so you can move your work over no problem.

[3axap4eHko]

Disable via Group Policy Editor

1. Press Win + R, type gpedit.msc, and press Enter.
2. Navigate to: User Configuration -> Administrative Templates -> Windows Components -> Attachment Manager.
3. Double-click on Do not preserve zone information in file attachments.
4. Set it to Enabled and click OK.

[nicolus]

In my opinion it is not the problem of Windows. Windows creates those files for every file downloaded from the internet by default using NTFS's Alternate Date Stream, so you don't see it in Windows native directories (but they are still there!). ext4 used by WSL doesn't support it, so it just creates it using usual API.

Indeed it's not a windows issue, and it's not an ext4 issue, everyone is behaving as they should.

However it's a very annoying WSL issue for most users so it doesn't mean a solution should not be found. Even if it's opt-in (for those users who for some reason would rely on seeing these files in WSL) and a workaround. It could just be an option to automatically ignore the zone.Identifiers file whenever you copy to a WSL mount.

[drewwiens]

Zone files don't get created in FAT drives when you copy files to them, so the correct implementation would not create zone files in any filesystem that doesn't support them including ext filesystems. Whether you consider a bug in Windows Subsystem for Linux to be a Windows issue or not is pretty irrelevant.

[Youjin1985]

Disable via Group Policy Editor

1. Press Win + R, type gpedit.msc, and press Enter.

2. Navigate to: User Configuration -> Administrative Templates -> Windows Components -> Attachment Manager.

3. Double-click on Do not preserve zone information in file attachments.

4. Set it to Enabled and click OK.

Does not work for me

[rts-corra]

This was working correctly for a bit with policy editor but now is again not working. W11

[tolgaulas]

Disable via Group Policy Editor

1. Press Win + R, type gpedit.msc, and press Enter.

2. Navigate to: User Configuration -> Administrative Templates -> Windows Components -> Attachment Manager.

3. Double-click on Do not preserve zone information in file attachments.

4. Set it to Enabled and click OK.

Does not work for me

Not working either. W11

[JordanVerda]

The posted solution of changing attachment manager setting does not work. Also checked the registry and I do have the value suggested there. How is there no solution to this yet? Nearly a 3 year old problem.

[AndreD23]

We can start organizing the birthday party for this issue. The date is coming! 🎂😅

[vladyslav-mikhieiev]

I'm tired and went back to macos 🤣

[Physikbuddha]

What seems to work is:
Open the "Internet Options" dialog from the start menu search or control panel, go to Security > Local intranet and click Sites, then Advanced. In the dialog, add *.wsl.localhost to the list. I've also added wsl$ myself, but that probably does nothing.

After that, I restarted explorer.exe and at least I'm not getting the Site.Identifier files anymore when I copy files to the WSL file system. Haven't tried downloading files yet, but it seems to do the trick or is at least a good start.

[tolgaulas]

What seems to work is: Open the "Internet Options" dialog from the start menu search or control panel, go to Security > Local intranet and click Sites, then Advanced. In the dialog, add *.wsl.localhost to the list. I've also added wsl$ myself, but that probably does nothing.

After that, I restarted explorer.exe and at least I'm not getting the Site.Identifier files anymore when I copy files to the WSL file system. Haven't tried downloading files yet, but it seems to do the trick or is at least a good start.

This did not work for me despite i followed each step, even retried with wsl$

Still getting Zone_Identified files when i copy files into wsl$ folders from explorer.

[AlexVFornazieri]

It issue is really so complex to sove or just miss people to contributing?

[italocjs]

Same issue! this keeps breaking scripts and github. workaround are not working

[dlil]

I see issues in both directions:

• Saving/copying files from an Internet zone into the WSL filesystem results in :Zone.Identifier files.
  • Workaround: manually delete the identifier files after copying, or use intermediate copies in the NTFS filesystem and manually remove zone attributes before copying to WSL.
  • Suggestion: If the filesystem supports zone attributes, then use that. Otherwise do nothing--do not create extra files (e.g. like how FAT partitions are handled, etc.).
• Creating files (e.g. tarballs) in WSL and then accessing via \\wsl.localhost\ (in Windows 11) triggers zone security warnings and such files have the Internet zone attribute set when copied out of the WSL filesystem.
  • Workaround: add the "*.wsl.localhost" site to the Local intranet zone in Internet Properties | Security
  • Suggestion: wsl.localhost should automatically be in the local intranet zone.

[NeuralClone]

What seems to work is: Open the "Internet Options" dialog from the start menu search or control panel, go to Security > Local intranet and click Sites, then Advanced. In the dialog, add *.wsl.localhost to the list. I've also added wsl$ myself, but that probably does nothing.

After that, I restarted explorer.exe and at least I'm not getting the Site.Identifier files anymore when I copy files to the WSL file system. Haven't tried downloading files yet, but it seems to do the trick or is at least a good start.

Unfortunately, these steps had no impact for me in Windows 11 Pro with all the latest updates (not including previews).

WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3880

[tolgaulas]

WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3880

I was on 2.1.1.0.. updated to the same version numbers above..

And i confirm it no longer creates site.identifier files when copying files into the wsl filesystem from explorer windows.. .

Thank you @NeuralClone !

[NeuralClone]

@tolgaulas If we're running the same versions of everything above and have different results, it makes me wonder what's different between our systems.

I've tried restarting explorer.exe multiple times and rebooted Windows a few times just to be safe. I'm still getting the identifier files when copying from Windows to WSL.

I don't have the opposite issue, though. I can copy files from WSL to Windows without the files being generated. So, that's good at least.

[tolgaulas]

@tolgaulas If we're running the same versions of everything above and have different results, it makes me wonder what's different between our systems.

I've tried restarting explorer.exe multiple times and rebooted Windows a few times just to be safe. I'm still getting the identifier files when copying from Windows to WSL.

I don't have the opposite issue, though. I can copy files from WSL to Windows without the files being generated. So, that's good at least.

No no. My first report was based on 2.1.1.0 and then updated mine to match yours and it worked on me.

I thought you were not getting them.. but it worked on me.. strange indedd.

[NeuralClone]

@tolgaulas If we're running the same versions of everything above and have different results, it makes me wonder what's different between our systems.
I've tried restarting explorer.exe multiple times and rebooted Windows a few times just to be safe. I'm still getting the identifier files when copying from Windows to WSL.
I don't have the opposite issue, though. I can copy files from WSL to Windows without the files being generated. So, that's good at least.

No no. My first report was based on 2.1.1.0 and then updated mine to match yours and it worked on me.

I thought you were not getting them.. but it worked on me.. strange indedd.

Oh ok. Gotcha. Unfortunately, I am indeed getting the files with the versions mentioned above. It's very strange that you upgrading to the same versions as me solved it for you. I'm glad it's working for some, though.

[wathika-eng]

you can sudo find . -name "*:Zone.Identifier" -type f -delete worst workaround, but works.

find /your/folder/name -type f -name "*.Identifier" -exec rm -f {} +

[Daniel-Standley]

I just created alias called dzi with the command

find . -name "*Zone.Identifier" -type f -delete

so easy to remove them when needed

[manfromarce]

This worked for me:

• open regedit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Attachments. It's essential that you use HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER, otherwise it is ignored for WSL
• add a new DWORD named SaveZoneInformation and set it to 1

Now browsers don't add the ZoneIdentifier stream for new downloads anymore. If it does not work for you, there is probably some other security configuration or version-specific bug that forces this feature.

[sglbl]

This worked for me:

• open regedit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Attachments. It's essential that you use HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER, otherwise it is ignored for WSL
• add a new DWORD named SaveZoneInformation and set it to 1

Now browsers don't add the ZoneIdentifier stream for new downloads anymore. If it does not work for you, there is probably some other security configuration or version-specific bug that forces this feature.

I tried this. I didn't try to download something from browser but when I try to extract from zip (winrar) to wsl location, it still creates the zone identifier files :(

[GitHunter0]

Is there an official explanation of this highly annoying issue? It's been years with no Microsoft feedback whatsoever