ADLS Blob Storage ACL继承规则及服务主体上传权限配置咨询

问题根因 #

该问题由ACL配置逻辑错误 + SDK选型不匹配共同导致，不属于Azure存储API的BUG。

1. ACL配置的核心问题

ADLS Gen2中，对象所有者并不天生拥有该对象的读写执行权限，仅默认拥有修改该对象ACL的权限，访问权限仍受ACL条目控制：

• 你当前仅在f3层级配置了默认ACL，f1、f2未配置默认ACL是符合要求的，不需要修改，父层级仅需保留my_sp的读+执行权限用于路径遍历即可。
• 你当前f3的默认ACL中仅配置了Owner的默认权限，但未显式给my_sp配置全层级继承的rwx权限：新创建的f5、f6文件夹继承f3的默认ACL时，仅给Owner条目配置了权限，而my_sp的权限未显式继承，导致上传时无写入权限。

2. SDK选型问题

你使用的azure.storage.blob.BlobClient是面向普通Blob存储的兼容接口，对ADLS Gen2的层级命名空间ACL继承逻辑支持不完善：直接上传带多级不存在父目录的路径时，自动创建的中间目录不会正确继承上级默认ACL，需要改用专门的ADLS Gen2 SDK。

正确配置方案 #

步骤1：修正ACL配置

• 保留现有c、f1、f2层级的ACL不变，满足父目录只读的要求。
• 在f3层级的默认ACL中，显式添加my_sp的rwx（读、写、执行）默认权限，确保所有f3下新创建的子文件夹、文件自动继承该权限，无需依赖所有者身份授权。
• 保留f3默认ACL中的mask为rwx，避免权限掩码过滤掉my_sp的写入权限。

步骤2：替换SDK调用（可选但推荐）

改用azure-storage-file-datalake库的DataLakeFileClient的upload_data方法执行上传，该接口原生支持层级命名空间的ACL继承规则，自动创建的中间目录会正确继承f3的默认ACL。

内容的提问来源于stack exchange，提问作者jugi