tldr: Windows bug presumably fixed in Windows 8
We ran into this problem when trying to copy some old data from one Windows file server to a NetApp NAS. We kept running into a problem where ROBOCOPY would fail to copy files:
2020/05/23 19:49:43 ERROR 6000 (0x00001770) Accessing Destination Directory l:\Somepath\folder\__MACOSX\
The specified file could not be encrypted.
As with your experience, it turned out that the files had been encrypted. Looking at the file properties showed that the users themselves had encrypted the files. When we interviewed the users, they claimed that they did not do this on purpose and didn't remember performing the steps (I showed them) to perform the encryption.
After some research, I found a link to an old Microsoft blog post, which has since been removed. Here is a link to the article on the Internet Archive and the text below.
https://web.archive.org/web/20131110020048/http://blogs.msdn.com/b/asklar/archive/2012/05/03/why-do-zip-files-from-mac-os-show-up-as-green-encrypted.aspx
Why do .zip files from Mac OS show up as green/encrypted?
It’s kind of funny really. The ZIP specification mandates that a program/OS creating a zip archive include a tag informing about itself to the program trying to decompress the archive. This information is called “version made by”, and looks like this:
0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
1 - Amiga 2 - OpenVMS
3 - UNIX 4 - VM/CMS
5 - Atari ST 6 - OS/2 H.P.F.S.
7 - Macintosh 8 - Z-System
9 - CP/M 10 - Windows NTFS
11 - MVS (OS/390 - Z/OS) 12 - VSE
13 - Acorn Risc 14 - VFAT
15 - alternate MVS 16 - BeOS
17 - Tandem 18 - OS/400
19 - OS/X (Darwin) 20 thru 255 - unused
Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.
The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.
The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…
Bonus question: can you change this behavior. Answer: No; but you can clear the encryption flag from the extracted files/folders easily.
Related to this problem, when the EFS Service on the Windows File Server performed the encryption, a local user profile was created for the user that copied the file. This had also been a mystery (since users don't have access to log into the File Server or otherwise run programs).
At the bottom of the post in the comments, the post's author mentions that the bug was fixed in Windows 8. I tried to reproduce the problem on Windows 10 and could not.
Unfortunately in each of our cases, the users computers had been rebuilt and they no longer had access to the certificates used to encrypt the files. We've since added an EFS recovery key account to prevent this from happening again, but since everyone is on Windows 10 it shouldn't happen anyway.
encrypt contents to secure data
, that will decrypt the contents. My suggestion would be to use something other then the built-in functionality to extract the contents of the archive.