Why does the uploaded file owner appear to be the user who accessed it

[junKLeee]

After mounting using blobfuse v1 in the container of Azure storage, the file was uploaded, and when the general user accessed it and checked it, the owner's authority appeared to be the user who accessed it Is this why it acts as a security factor?

[vibhansa-msft]

We do not maintain the file ownership info on the storage container (as its not supported by the Azure Storage itself). File ownership will always point to the user who has mounted the file-system unless you use "uid/gid" flags while mounting. Also, if you are using blobfuse v1, kindly upgrade to v2 as v1 will not have any further releases.

[junKLeee]

For your information, we are using a hierarchy for the adls type

[vibhansa-msft]

As your account is HNS enabled, did you mention --use-adls=true in cli option.
Also, you uploaded the file using blobfuse2 or Azure Portal (little confused based on your above comments). If you have used blobfuse2 and "streaming" was enabled, kindly revert back to file-cache option as we have observed some issues with streaming when files are uploaded.
Disabling writeback cache will degrade the performance, this is by design. If you can share your mount command and config file may be we can look at parameter tuning part.

[vibhansa-msft]

as I suspected, you are using stream option and that has some issue with uploads which I am investigating right now (#1142)

[vibhansa-msft]

better you switch to file-cache model which will work fine for your case unless your files are very huge in size.

[junKLeee]

[vibhansa-msft]

components:
- libfuse
- file_cache
- attr_cache
- azstorage

[vibhansa-msft]

file_cache:
path: "a temp directory path"
cleanup-on-start: true
timeout-sec: 120

[vibhansa-msft]

you mount is successful with suggested option or not ? If so, can you first try reading/writing to file locally from the linux vm where you mounted and validate things are working fine.

[vibhansa-msft]

file-cache is supported for both block and adls account.
For duplicate files can you share the logs from blobfuse to dig this deeper.

[vibhansa-msft]

"https://kbidqa1krcimgst001.dfs.core.windows.net/imgstorage01//imguploaddev/portal/portal/2023/05/02/3?timeout=901#012 " : why are there two "//" in the URI. You might have given some wrong config somewhere and that might be the reason for this failure.

[junKLeee]

It's settled. Thank you very much !!