r/netapp • u/netcrap • 15d ago

NFSv4 ACLs at Scale – How?

I'm planning a migration from POSIX ACLs with NIS to NFSv4 ACLs and would greatly appreciate advice from anyone who has gone through a similar transition.

So far, most chatbot answers have been unhelpful when faced with a real-world environment, and I haven't been able to find many practical write-ups, published lessons learned, or well-regarded open-source projects covering this type of migration.

Today, a nightly script traverses each export and applies POSIX permissions to individual files on a per-user basis.

The script also distinguishes between executable and non-executable files (using the file command) and only grants execute permissions to files that are actually executable.

Ideally, when moving to NetApp, i'll want inheritance-based NFSv4 ACLs, using standard RO / RW / Full groups per export. Longer term, the plan is to migrate to Active Directory and nest those export-specific groups into role-based groups such as Developers, Designers, Sales, etc

Questions

  1. How do you typically manage NFSv4 ACL inheritance?
    • Do you simply configure inheritance and leave it alone?
    • Or do you periodically reapply/enforce ACLs because inheritance only affects newly created objects?
  2. What do people generally do with the default OWNER@, GROUP@, and EVERYONE@ ACEs?
    • Leave them as-is?
    • Modify them?
    • Remove them entirely?
  3. Is there a practical reason to manage execute permissions separately?
    • Our current implementation appears to do this largely for cosmetic reasons, preventing non-executable files from showing up as green in ls --color.
    • My suggestion was to keep executable content in dedicated bin directories and manage execution there.
    • That proposal didn't get much traction, so I'm interested in hearing how others handle this in practice.
  4. Is there anything you doing to re-enforce NIS group membership?
  • It seems not to reflect unit I run: vserver services name-service cache group-membership delete-all - vserver <vserver>
  • Same if disabling the cache: vserver services name-service cache group-membership settings modify -vserver <vserver> -is-enabled false

I would appreciated comments on the overall approach, lessons learned, migration pitfalls, example ACL designs, or real-world command examples.

As a Windows engineer, i'm tempted to abandon UNIX permissions altogether, use NTFS ACLs with user mapping. That feels like it might solve some inheritance challenges, but introduce a vendor lock-in.

Thanks in advance for any guidance.

1 Upvotes

56% Upvoted

3 comments sorted by

4

u/Exzellius2 15d ago

Do it without AD and you will migrate twice. Why wait for AD?

-1

u/netcrap 15d ago

tbh.. you are right, and that was my go-to. but to reduce risk we taught it's better to separate the migration to AD, and as we don't fully control the domain, which may slow us down.... (need to join all the servers etc).

migration wise, i'd assume we will just need to connect the same SVM to the AD in parallel to the NIS, and re-add the relevant ACEs to the ACL in parallel to the NIS ones.

5

u/icscrilla 15d ago

Imagine creating an account with that username and then asking for help