File services permissions FA

Short answer: no—Purity doesn’t let you set per-file or per-folder ACLs in the array UI/CLI.
You define share/export settings on the array, but file-level permissions are set from the clients and enforced by the array:

• SMB/NTFS: Join the array to Active Directory, then manage NTFS ACLs from Windows tools (Explorer, icacls, PowerShell). The array honors those ACLs; AD integration is configured on the array. 
• NFS: Permissions come from POSIX mode bits and, where in use, NFSv4 ACLs—again set from the client (e.g., chmod, setfacl/nfs4_setfacl). 
  
  
• Multiprotocol (esp. FlashBlade): You choose an access control style (NFS/SMB/shared/etc.) that dictates how client-set file/directory ACLs behave; ACLs themselves are set on clients, not in Purity. 

So: manage ACLs at the OS level; manage shares/exports, quotas, snapshots, and directory-services integration in Purity. Some older FlashBlade docs also note the default Unix-style permissions with optional Windows ACL support when AD-joined, reinforcing that ACLs are client-driven. 

But you can potentially cheat your way in by using ....

Workaround: 1 folder = 1 share/export

Idea: put every sensitive folder behind its own SMB share or NFS export and gate access at the share/export policy, not inside the folder.

SMB (Windows)

Create a managed directory (e.g., /data/Finance).

Create an SMB share that points to that directory (e.g., FINANCE$ to hide it from browsing).

Allow only the right AD groups at the share (RW/RO) and push drive mappings via GPO. Optionally front it with DFS links and turn on Access-Based Enumeration so users only see links they can open. 

NFS (Linux/Unix)

Create the managed directory (e.g., /data/Analytics).

Create an NFS export for that directory and use an NFS policy that restricts client IPs/netgroups and RO/RW. (You can create exports per subdirectory; see Ansible example below.) 

Scale it with automation 

- hosts: localhost
  gather_facts: no
  vars:
    fa_url: 10.10.10.2
    api_token: xxxxx
    filesystem: corpdata
    folders:
      - { name: finance,  dir: finance,  nfs_policy: nfs-finance,  smb_policy: smb-finance }
      - { name: hr,       dir: hr,       nfs_policy: nfs-hr,       smb_policy: smb-hr }
  tasks:
    - name: Ensure NFS policies exist (restrict clients, set ro/rw as needed)
      purestorage.flasharray.purefa_policy:
        fa_url: "{{ fa_url }}"
        api_token: "{{ api_token }}"
        name: "{{ item.nfs_policy }}"
        policy: nfs
        client: "netgroup_or_ip"
        nfs_permission: rw
        nfs_access: no-root-squash
      loop: "{{ folders }}"

    - name: Create per-folder exports (SMB and/or NFS)
      purestorage.flasharray.purefa_export:
        fa_url: "{{ fa_url }}"
        api_token: "{{ api_token }}"
        name: "{{ item.name }}"
        filesystem: "{{ filesystem }}"
        directory: "{{ item.dir }}"
        nfs_policy: "{{ item.nfs_policy }}"
        smb_policy: "{{ item.smb_policy }}"
      loop: "{{ folders }}"

• No “parent” catch-all share/export. Otherwise users could bypass the folder boundary.
• Multiprotocol caution: If a folder is SMB-only, don’t also export it via NFS (and vice-versa). If you must mix, align rules carefully to avoid bypass. (FlashBlade exposes control styles for multi-protocol; principle still applies.)
• Visibility & UX: Use $ in SMB share names or DFS with ABE so users only see what they can open.
• Quotas/Capacity: Consider quotas to keep each share in bounds (feature available in FA File Services).

Bottom line: This pattern gives you clean, auditable boundaries

one folder = one share/export = one policy

without relying on array-side per-file ACLs.

Hope it helps, Garry Ohanian

Hello Djalma, currently there is no Purity UX for editing file level permissions. I would be interested in learning more about the workflow this would be used for and how to secure it.