Wrong permissions on mkdir after April beta update

[ylluminate]

When I do an mkdir in some folders I'm finding that they're being created with 555 permission instead of 755. Any idea about what could be going on here?

[ylluminate]

I have also noticed now that, for example, iTunes will no longer open, saying that: "The iTunes Library.itl file is locked, on a locked disk, or you do not have write permission for this file."

This has been working fine for the last couple years and so this is a new development. I am running 10.13.5 Beta (17F70a), so I'm curious if that has something to do with this issue.

EDIT: Now that I am thinking about the timeline, while the beta ZFS update was installed in close proximity to the new build from Apple, I believe that this is an issue that happened AFTER the new build from Apple...

[lundman]

have a beta VM, so I'll get 10.13.5 on there and see what breaks!

[ylluminate]

Hey thanks so much. I just installed from source and the same problem. It appears that permissions are just not being set properly as I'm still getting folders with 555 vs 750, etc. by default. Even after manually changing, still getting write problems.

[lundman]

bash-3.2# sw_vers
ProductName:    Mac OS X
ProductVersion: 10.13.5
BuildVersion:   17F70a

bash-3.2# sudo -u lundman mkdir /Volumes/BOOM/world
bash-3.2# ls -la /Volumes/BOOM/
total 5
drwxrwxrwx  6 root     wheel    6 May 21 09:27 .
drwxr-xr-x@ 6 root     wheel  204 May 21 09:26 ..
d-wx-wx-wt  2 root     wheel    2 May 21 09:26 .Trashes
drwx------  3 root     wheel    3 May 21 09:26 .fseventsd
drwxr-xr-x  2 lundman  staff    2 May 21 09:27 world

Seems normal. You sure you dont have umask set to something weird?

# umask
0022

[ylluminate]

No, I have 022 as well with no issues otherwise...

What can I do to diagnose the issue further since it appears to be isolated to me for some reason?

[lundman]

Maybe you can do a

dtruss -f mkdir $path

[ylluminate]

$ cd \path\to\tank
$ sudo dtruss -f mkdir test
    PID/THRD  SYSCALL(args)          = return

$ ls -trlah |grep test
dr-xr-xr-x      2 root      staff     2B May 21 00:48 test

Then when I go back to my APFS volume (user home folder):

$ cd \Users\username
$ sudo dtruss -f mkdir test
    PID/THRD  SYSCALL(args)          = return

$ ls -trlah |grep test
drwxr-xr-x     2 root      staff    64B May 21 00:52 test

[lundman]

Oh I guess that was a boring suggestion.

[ylluminate]

I've been digging around to see if I can get dtruss working again for 10.13.x, but it seems as though it's broken. I haven't been able to find any details on it.

In the mean time, I've also found that some smb shares are hanging a client when I attempt to access SMB shares from the ZFS tank. Further, I've found that if I share them via AFP, I get "Bad file descriptor" for many of the files and folders in the tank.

I have to think I have some strange things going on as far as permissions go. I don't have any particular permissions that I need to retain here, do you have some incantations for resetting all permissions across a tank that you find handy to make sure permissions are set at the "sanity" level?...

One thing I'd like to do is to gather ALL permissions (including ACLs, or anything else that could be hidden) and compare them to the APFS and HFS volumes that are sane. Are you aware of how to get every single bit that matters to diff them?

[ylluminate]

@lundman I may have just "resolved" the issue (definitely not solved though!). I'm not sure what on earth could have provoked this behavior initially as the only differential was the new ZFS beta + the new beta build, but I did the following:

I examined and modified the PARENT folder of the test folder that was screwed up in it's permissions via:

test root $ cd ..; rm -fr test
parent root $ ls -laeO@tr . | tail   # didn't reveal anything too exciting except some `com.apple.FinderInfo` attributes on `.` and `..`.
parent root $ xattr -l .             # again, not much of interest from what I can tell

# I then just decided to wipe everything out as best I could:

parent root $ chown -R username:staff .
parent root $ chflags -R nouchg .
parent root $ chflags -R noschg .
parent root $ chmod -h -N .
parent root $ chmod -R -L -N .

After I did this I was able to make a test folder now and it had the appropriate 755 permissions... I don't know what to think!

[hoondi]

whenever I create a new pool, the first thing I do is:

sudo zfs set reservation=1m $poolname

sudo zfs set com.apple.mimic_hfs=on $poolname

sudo chown -Rf unknown:staff /Volumes/$poolname

sudo chmod o-rwx /Volumes/$poolname

sudo chmod -RN /Volumes/$poolname

and on occasion I perform the following:

sudo chmod -R +a "admin allow delete,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,list,search,add_file,add_subdirectory,delete_child,list,search,add_file,add_subdirectory,delete_child" /Volumes/$poolname

I’ve hosted iTunes & iPhoto/Photos libraries on ZFS for over a decade now using NFS/AFP/SMB without an issue.

On 23 May 2018, at 5:52 am, ylluminate notifications@github.com wrote:

@lundman https://github.com/lundman I may have just "resolved" the issue (definitely not solved though!). I'm not sure what on earth could have provoked this behavior initially as the only differential was the new ZFS beta + the new beta build, but I did the following:

I examined the parent folder in question via:

ls -laeO@tr . | tail # didn't reveal anything too exciting except some com.apple.FinderInfo attributes on . and ... xattr -l . # again, not much of interest from what I can tell

I then just decided to wipe everything out as best I could:

chown -R username:staff . chflags -R nouchg . chflags -R noschg . chmod -h -N . chmod -R -L -N . After I did this I was able to make a test folder now and it had the appropriate 755 permissions... I don't know what to think!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openzfsonosx/zfs/issues/641#issuecomment-391119110, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkh1U2fUoFLoDLedVmC8VEJBCuUcYSgks5t1GyOgaJpZM4T_6B9.

[ylluminate]

Interesting @hoondi. I have caught a few of those before, but I'd be curious if you'd please put a # comment to the side of each incantation to just delineate a little more of your logic on why you execute each item...

I'm particularly interested in the last incantation wherein you set admin ACLs vs user. Also, some of these, in theory, should not be necessary since you were saying you apply these to a fresh pool, unless some of the system folders start off "funky."

[hoondi]

Okay,

Here goes…

sudo zfs set reservation=1m $poolname

You never want a pool to be 100% full. It’s not fun to fix in puts you in a catch-22 situation. (plus a red face!)

When a pool does reach 100%, deleting any files via terminal or Finder must actually write data to the pool first, which is intrinsic to Copy On Write filesystems…

The only way around this scenario is to manually edit sectors on disk, which is full-on low level stuff that I never want to have to do. Much easier to reserve space right at the get go.

sudo zfs set com.apple.mimic_hfs=on $poolname

keep macOS happy.

sudo chown -Rf unknown:staff /Volumes/$poolname

The user “unknown” is a system generated service account.

If you looked at all the permissions of service accounts, the user unknown is at the opposite end of the spectrum when compared to the root user.

Here’s an example: If you create a folder in /Users/Shared/ and change it’s owner to unknown, anyone else who logs in and get-info on the folder will appear as if they own the folder.

Very handy command when initally setting up group network shares and wanting to wipe out POSIX and just rely and Apple’s Access Control Lists (ACLs).

The usergroup staff is just the default/primary group that macOS assigns to any newly created user account.

sudo chmod o-rwx /Volumes/$poolname

Keep “others” out of being able to read, write or execute.

I’ve noticed that sometimes the macOS service account “Guest” gets enabled on people’s machines at times. I presume this happens when certain services are enabled.

So I like to ensure I’m not exposing any datasets to the guest account.

sudo chmod -RN /Volumes/$poolname

Recursively remove all existing ACLs, which is also handy when setting up a new network share.

You can check this using ls -le

sudo chmod -R +ai "admin allow delete,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit,list,search,add_file,add_subdirectory,delete_child,list,search,add_file,add_subdirectory,delete_child" /Volumes/$poolname

So I clearly prefer to use ACLs to manage files these days as they are far more flexible and powerful than POSIX. But more complicated too.

I think my first post didn’t have the “i” in “-R +ai” which should really be there, so any newly created files/folders inherit the attributes.

the example above is for users in the admin group, but ACLs can be applied to users and groups

Do have a good thorough read about ACLs (man chmod) as they are quite powerful.

Cheers,

On 24 May 2018, at 11:54 am, ylluminate notifications@github.com wrote:

Interesting @hoondi https://github.com/hoondi. I have caught a few of those before, but I'd be curious if you'd please put a # comment to the side of each incantation to just delineate a little more of your logic on why you execute each item...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openzfsonosx/zfs/issues/641#issuecomment-391562167, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkh1fslySPFSbZ5ebQWYgk-xDX-GfcUks5t1hLDgaJpZM4T_6B9.

[ylluminate]

Thanks so much @hoondi. I pretty much got everything you were doing at a technical level, but it was really fantastic to see your reasoning a few of the points as I wasn't grokking exactly their use case in this situation completely. Thanks so much for that!

I have a rather simple share scenario here in the office and so I usually try to fixate on POSIX perms and stay away from ACLs since they've caused me some real headaches over the years. Further it appears that setting or removing some permissions causes kernel memory usage to skyrocket and it doesn't make it through my entire tank without seizing up the system pretty severely, even with 128 GB of RAM.

[hoondi]

mmm,

Perhaps break up your chmod command by top level folders instead of hitting the entire pool at once? I’m assuming you’re using Terminal and not the Finder as I haven’t trusted the Finder for ACLs for quite some time now...

On 29 May 2018, at 1:39 am, ylluminate notifications@github.com wrote:

Thanks so much @hoondi https://github.com/hoondi. I pretty much got everything you were doing at a technical level, but it was really fantastic to see your reasoning a few of the points as I wasn't grokking exactly their use case in this situation completely. Thanks so much for that!

I have a rather simple share scenario here in the office and so I usually try to fixate on POSIX perms and stay away from ACLs since they've caused me some real headaches over the years. Further it appears that setting or removing some permissions causes kernel memory usage to skyrocket and it doesn't make it through my entire tank without seizing up the system pretty severely, even with 128 GB of RAM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openzfsonosx/zfs/issues/641#issuecomment-392557424, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkh1bZIqRYmdk7sfMcEOSMcT3VnnAG7ks5t3BotgaJpZM4T_6B9.