Permission Denied on Parent Datasets

[gbooker]

I just upgraded from FreeNAS-9.3-STABLE-201601181840 to FreeNAS-9.3-STABLE-201602031011 and noticed my shell's git module was constantly complaining that it couldn't stat .. whenever I was in a dataset with windows permissions. It did not do this before the OS upgrade and the permissions on the relevant directories did not change. I noticed that I cannot "stat .." in many cases, but if I change to the parent directory I can "stat ." without issue. What I am seeing:

gbooker@pond:/mnt/pond/archive/Software
[3528] % getfacl .
# file: .
# owner: gbooker
# group: gbooker
owner@:rwxpDdaARWcCo-:fd----:allow
fatal: failed to stat '/mnt/pond/archive/Software/..': Permission denied
gbooker@pond:/mnt/pond/archive/Software
[3529] % getfacl ..
getfacl: ..: stat() failed: Permission denied
fatal: failed to stat '/mnt/pond/archive/Software/..': Permission denied
gbooker@pond:/mnt/pond/archive/Software
[3530] % sudo getfacl ..
Password:
# file: ..
# owner: gbooker
# group: gbooker
owner@:rwxpDdaARWcCo-:fd----:allow
fatal: failed to stat '/mnt/pond/archive/Software/..': Permission denied
gbooker@pond:/mnt/pond/archive/Software
[3531] % cd ..
gbooker@pond:/mnt/pond/archive
[3532] % getfacl .
# file: .
# owner: gbooker
# group: gbooker
owner@:rwxpDdaARWcCo-:fd----:allow
gbooker@pond:/mnt/pond/archive
[3533] % zfs get aclmode,aclinherit pond pond/archive pond/archive/Server
NAME PROPERTY VALUE SOURCE
pond aclmode passthrough local
pond aclinherit passthrough local
pond/archive aclmode restricted local
pond/archive aclinherit passthrough inherited from pond
pond/archive/Server aclmode restricted inherited from pond/archive
pond/archive/Server aclinherit passthrough inherited from pond

In the above, pond is the main dataset using unix permissions, where pond/archive and pond/archive/Server use windows permissions. The "fatal: failed to stat '/mnt/pond/archive/Software/..': Permission denied" is coming from my shell's git integration.

What I find particularly interesting is that I cannot "getfacl .." but I can sudo it even though I am the owner and have all permissions (except for sync). Furthermore, if I "cd ..", then I can "getfacl ." This seems to only occur when the parent directory is a parent dataset and both are using windows style permissions (doesn't seem to occur when the parent dataset is using unix style permissions).

Is this a bug in FreeNAS or are my permissions screwy and the upgrade simply exposed the issue? I didn't find anything in searching the forums, bug reports, or google in general. Let me know if any other information is needed.

 

[gbooker]

Doing a bit more diagnosis, I can reproduce this with new datasets:

1. Create dataset with windows share type and change permissions to set the owner to your user
2. SSH in and cd to that dataset. Run: setfacl -m "owner@:rwxpDdaARWcCo-:fd----:allow" .; setfacl -x "group@::allow" .; setfacl -x "everyone@::allow"
   
3. Create a child dataset with windows permissions
4. cd into that child dataset and notice the following command fails: stat ..

I've also discovered how to fix this. If you unmount the child dataset, the parent dataset has a directory for the child dataset, but that directory's permissions do not match the child dataset's root permissions. In my case it was:

# file: Software
# owner: root
# group: gbooker
owner@:rwxpDdaARWcCo-:fd----:allow

Notice the owner is not my user, but when the dataset is mounted, the owner is my user. So, I've discovered I can solve this by unmounting child datasets, change the owner on the mountpoint locations, and then remount the child datasets. I don't know if this survives a reboot, but it seems to work for now.

 

[dlavigne]

That's interesting. If you decide to report this at bugs.freenas.org, post the issue number here.

 

[gbooker]

I suppose this should be reported:
https://bugs.freenas.org/issues/13527