At work I manage a group responsible for data management and security. We have a need to specify complex permissions on files and folders beyond just the standard user/group/world rwx. Research shows this can be done with extended file attributes (setfacl, getfacl commands) on filers running NFSv4. The filers at work are running NFSv3. Whenever I ask the IT group regarding conversion, they always reply with "it is too slow, too hard, not safe or stable, etc" to upgrade to NFSv4 without providing data or timelines to substantiate the claims. As a result, we end up creating multiple copies of data where directoryA has files which groupA can view and directoryB has files which groupB can view.

I was wondering a couple of things:

  1. are the claims true? Does conversion from NFSv3 to NFSv4 with extended file attributes enabled severly impact performance? are there other items to consider? for example, I assume some applications may not be coded to properly interpret these extended file attributes.
  2. Besides acls on NFSv4, is there another solution or method for applying complex permissions? the majority of machines at work are running either SLES11 or SLES12.

Appreciate any help or direction you can offer...thanks!

  • 1
    NFSv3 dates back to 1995. Nobody anywhere should still be using it with bogus excuses like those. Aug 23, 2020 at 14:09

1 Answer 1


NFS 4 can be a lot safer and it's surely stable, available since 2003 if I recall well. There are newer versions also, 4.1 & 4.2. It's quite easy to upgrade, if you don't enable any of the advanced features.

  1. Performance may be a bit better on nfs 3, due to using udp & tcp; nfs 4 is tcp only. But that doesn't really make such a big difference on most scenarios. Actually it can be compensated, because in tcp when packets are lost only these lost packets are retransmitted, contrary to udp. There's also delegation on nfs 4, which can improve performance. Encryption can impact performance a lot, but that's a choice, it's not mandatory to use higher security standards on nfs 4, yet they are available if needed.
    I can't really tell about application incompatibilities using nfs v4. I've used it for file copy-move operations and video streaming without problems.

  2. Cannot give you a definitive answer on this, though I think the absence of alternatives gave birth to nfs v4. SMB/CIFS could be used; I don't consider it a native alternative because it's a Windows protocol, yet the UNIX/Linux implemantation is excellent. Although I suppose it would be a bigger chalenge to implement it on Linux servers and clients than nfs v4.

A reason that your IT team is reluctant to switch to v4 may be OS compatibility and support: Both servers and clients must support it. Perhaps there are older OSes, SLES 11 without SPs for example, which are not supported by SuSE and they prefer to avoid changing settings on them.

There's also the option to share using both nfs v3 & v4. You could test it on some directories before proceeding to fully switch to v4.

  • Any OS that is still in support can be an NFSv4 client. And many that aren't still in support. It's that mature. Now maybe if they're still running Windows 98... Aug 23, 2020 at 14:11
  • Yes, sure, I meant technical support by the vendor; perhaps the IT doesn't feel confident to make changes without it. SLES 11 prior to SP4 is out of support I think.
    – Krackout
    Aug 23, 2020 at 15:12
  • That would be a rather odd excuse too; NFSv4 is much simpler than v3. Enough so that anybody who can manage to install an OS can probably deploy it. But it wouldn't be the first incompetent IT department I've seen... Aug 23, 2020 at 15:30
  • If performance of parallel opens are important, then you should go for nfs v4.1. It has almost the same performance as nfs3, but has all goodies, like ACL, locking, reply cache.
    – kofemann
    Aug 24, 2020 at 7:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .