Fail to download files or folders that were not originally uploaded to the file share on Windows

[v-xianya]

Storage Explorer Version

1.40.0 (108)

Regression From

1.39.1

Architecture

arm64

Storage Explorer Build Number

20250925.2

Platform

All

OS Version

Windows11 arm64/Windows11 x64

Bug Description

Fail to download files or folders that were not originally uploaded to the file share.

Both reproduces for File Shares under Standard StorageV2 storage accounts/SMB file shares under Premium storage accounts.

Resource Types

File Shares

Authentication Method

Sign in

Connection Type

Sign in (subscription)

Steps to Reproduce

1. Expand one storage account -> File Shares.
2. Create a new file share -> Create a folder.
3. Download the folder.
4. Check whether there is a successful activity log.

Actual Experience

1. There is a failed activity log.
2. The folder is downloaded successfully.

AzCopy Log:

16f4b54a-a36f-de4a-549b-7b587f6f14b0.log

Expected Experience

There is a successful activity log.

Additional Context

1. This issue doesn't reproduce on MacOS and Linux.
2. This issue also reproduces for SMB file shares under File Premium storage account on Windows. 3.Here are the details for downloading files. AzCopy Log: cd66a229-5b6f-244b-779c-5f3745804b23.log

[craxal]

I think this line in the log is telling:

2025/09/25 09:00:35 ERR: [P#0-T#0] DOWNLOADFAILED: https://0925adlsy.file.core.windows.net/fs-01/file01.txt : 000 : permissions could not be restored. It may help to add --preserve-owner=false to the AzCopy command line (so that ACLS will be preserved but ownership will not). Or, if you want to preserve ownership, then run from a elevated command prompt or from an account in the Backup Operators group, and set the 'backup' flag. NT status was: STATUS_INVALID_OWNER. When Setting destination file SDDLs. X-Ms-Request-Id:

I will attempt to reproduce, try again using AzCopy directly, then try with the suggested option.

[craxal]

I was able to reproduce the issue, but only when Preserve Permissions is enabled. I seem to recall there being higher chances of failure if the original Preserve SMB Permissions option was enabled. This seems congruent with the NFS behavior. The underlying reason is simple: when you create a folder (or upload a file) through Storage Explorer, we don't include any ownership information. So, Azure creates it using the default (root) user as the owner. When downloading the folder or file, it can't properly preserve the owner, because the user doesn't have permission to modify ownership without elevated privileges.

I was able to work around the issue by running the AzCopy command directly and adding the --preserve-owner=false option.

All in all, I don't think this is a blocking issue. I do think it suggests we need to investigate whether we can upload or create items with ownership info.

[craxal]

Similar to #8745, this is largely due to a bug in AzCopy. Once a fix is integrated, and --preserve-permissions is disabled, transfers should succeed.

https://msazure.visualstudio.com/One/_workitems/edit/35144712

[craxal]

@v-xianya Fixes related to --preserve-permissions have been merged. Can you verify whether this is fixed?

[v-xianya]

Verified this issue on the main build 20251218.1. Downloading the folder succeeds when --preserve-permissions is disabled. Downloading the folder fails when --preserve-permissions is enabled,

[craxal]

@v-xianya It's very possible that the files/folders "not originally uploaded" by you failing to download could be because the owner in the share doesn't exist on your local filesystem. Does the issue occur if you run the AzCopy command separately? If so, does adding the --preserve-owner=false work if --preserve-permissions is enabled?

[v-xianya]

Hi @craxal Verified using the build 20251912.1。 Downloads failed when running the AzCopy command alone. The download completed successfully when --preserve-owner=false was added while --preserve-permissions was enabled.