I have an NFS drive mounted:

/../Volumes/PDISK2         -fstype=nfs,nolockd,rw nfs://
/../Volumes/PDISK3         -fstype=nfs,nolockd,rw nfs://

Taking PDISK3, as an example, its directory structure looks like this:


Everything but FolderA is rwxrwxrwx, but FolderA is rwxrwx---.

In Finder, I can copy files to, create directories in, rename files in, etc every directory. However, if I try to delete a folder that I just created in FolderA (or any subdirectory), it fails - but works everywhere else. The Terminal has no problem deleting the files Finder complains it couldn't delete:

The operation can't be completed because you don't have permission to access some of the items.

As a sidetone, the permissions of the directory Finder creates are rwxr-xr-x.

I have no idea what would be causing this. Any suggestions would be greatly appreciated.

Another oddity is that if I go to /Volumes/PDISK3/path/to/folder, drag that folder into Finder's sidebar, click on it in the sidebar, then drag a file from there to the terminal, it instead reports its path as /net/, though this does seem to be affecting the finder-can't-delete-stuff problem.

Here's some other information from mount:

[defiant:/] christopher% mount | grep PDISK3
map auto_nfs on /Volumes/PDISK3 (autofs, automounted, nobrowse) on /net/ (nfs, nodev, nosuid, automounted, nobrowse) on /Volumes/PDISK3 (nfs, nodded, nosuid, automounted, nobrowse)

More Information:

The offending directory is owned by root and I am in the group. root and the group have rwx access. Others have --- access. With those settings, Finder cannot delete things.

If I chmod -R o=x (i.e. rwxrwx--x), Finder can delete things.

If I'm in a directory I own, Finder does not need execute privileges, but if I am merely in the group it does need execute privileges for other.

So, why does Finder need execute privileges on other for things I'm in the group of?

Bug Report Submitted To Apple

Here are the computers involved

  • Nexus: OS X El Capitan Server as Open Directory Master
  • FS1: Linux Mint server (NFS4) bound to Nexus's directory (via ldap)
  • Defiant: El Capitan Retina MacBook Pro (also bound to Nexus)

Here are the users/groups involved:

  • User root
  • Group family
  • User christopher (member of family)

FS1 has several drives shared via NFS. One of which has this example directory structure & permissions:

Drive/ # root/family rwxrwxrwx Drive/FolderA # root/family rwxrwx--- Drive/FolderA/SubdirA # christopher/family rwxrwx--- Drive/FolderA/SubdirB # root/family rwxrwx--- Drive/FolderB

This problem does not change if I access the share by /net/ or if I mount it at some location in my filesystem so I will omit the details of mounting.

The problem:

In Finder on Defiant, I can easily do all of the following actions:

  • Create a directory Drive/FolderA/SubdirA/asdf
  • Rename Drive/FolderA/SubdirA/asdf to Drive/FolderA/SubdirA/blablabla
  • Put stuff in Drive/FolderA/SubdirA/blablabla
  • Delete stuff in Drive/FolderA/SubdirA/blablabla
  • Delete Drive/FolderA/SubdirA/blablabla

  • Create a directory Drive/FolderA/asdf

  • Rename Drive/FolderA/asdf to Drive/FolderA/blablabla
  • Put stuff in Drive/FolderA/blablabla
  • Delete stuff in Drive/FolderA/blablabla

However, if I then try to delete Drive/FolderA/blablabla, I get this error from Finder:

"The operation can't be completed because you don't have permission to access some of the items."

Which is clearly false because I have RWX access because I am in the group and I successfully performed several other actions.

There are a few ways I can remedy this situation:

************ WORKAROUND #1 ************

If I change permissions of Drive/FolderA to root/family rwxrwx--x (i.e. add the execute flag, but not the read/write flags), I can successfully delete items in the directory. However, this required me to change permissions of a directory to less-secure ones which is a security concern.

************ WORKAROUND #2 ************

Enable no_root_squash on the nfs server but keeping the permissions the same. This allows the client computer to successfully remove the file, but required the server to allow root access everywhere which is a security concern.

************ WORKAROUND #3 ************

This is the best one: use the Terminal (still on Defiant!). Given the example above without any permissions modifications, the terminal can successfully remove the directory created by the Finder. This shows that it is a problem with the Finder, not with the NFS server or permissions.


If Finder tried to escalate [automatically?!?] to root to perform a deletion operation, the nfs server would convert root to nobody, which therefore falls under the 'other' part of the permissions, and therefore requires additional permissions. Disabling root-squash allows the root access through, so that works.

However, this is all localized to the Finder.

  • Did you try checking the ACL? Try this command on the directories in question: ls -led – William T Froggard Feb 1 '16 at 16:51
  • 1
    @jefe2000 Is there anything else he could possibly mean? – William T Froggard Feb 1 '16 at 22:47
  • Instead of deleting, Finder is probably trying to move the file to the .Trashes folder on the NFS drive; and, that is where your permission failure is occurring. – Kent Feb 2 '16 at 0:10
  • When I try to delete it from the Finder, it first says "Are you sure you want to delete "asdf"? This item will be deleted immediately. You can't undo this action." So it appears to not be moving it to .Trashes. – iAdjunct Feb 2 '16 at 1:44
  • ls -led doesn't show anything besides the normal owner (me), group (staff), and the permissions (rwxr-xr-x). – iAdjunct Feb 2 '16 at 1:46

You must log in to answer this question.

Browse other questions tagged .