EncryptedExcelIsNotSupported issue with no password protection

Question

Hello team,

I am having an issue when reading an Excel file with a Copy activity.

Some context:

• The Excel files have been created with Excel 2007
• The files were previously encrypted, but they are now unencrypted and have no password (I also check from the compatibility tab and it seems fine)
• By saving the files again as xlsx (same format as before) they seem to be readable by ADF (Save As option).

The same process used to work at the beginning of last month, but it has been broken for a couple of weeks. We are also investigating on the source system to see if there have been changes.

Could anyone please tell me if they had similar issues?

Thank you!

Riccardo

I am leaving the error details for readability:
ErrorCode=EncryptedExcelIsNotSupported,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Encrypted excel file '20251005.xlsx' is not supported, please remove its password.,Source=Microsoft.DataTransfer.ClientLibrary,''Type=ICSharpCode.SharpZipLib.Zip.ZipException,Message=Wrong Local header signature: 0x495,Source=ICSharpCode.SharpZipLib,'

Answer 1

hi Riccardo,

the error says the file is encrypted, but you've confirmed it's not password protected. this discrepancy points to a file corruption or a hidden property that makes ADF think the file is still encrypted.

the key clue is that re saving the file as xlsx fixes the problem. this strongly suggests that the original files have some kind of corrupted zip structure or leftover encryption metadata in their headers. excel files (.xlsx) are essentially zip archives, and if that structure is damaged, ADF's zip library fails to read it and throws this misleading error.

since the process worked a month ago, something changed in the file generation process on your source system. your investigation there is the right path.

library or tool update, was there an update to the software or library that generates these excel files? a new version might be introducing a subtle change in how the zip container is built.

process change,, has the process for "un encrypting" the files changed? maybe a step is being skipped, leaving the file in a weird state.

if you cannot immediately fix the source, you could use an azure function or a logic app as an intermediate step. this service could programmatically open and re save the file (as your manual process does) before ADF tries to read it.

the files are likely corrupted, not encrypted. your focus should be on finding what changed in the source system's file generation process about two weeks ago.

regards,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/