Open ylluminate opened 6 years ago
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...
have a beta VM, so I'll get 10.13.5 on there and see what breaks!
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.
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
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?
Maybe you can do a
dtruss -f mkdir $path
$ 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
Oh I guess that was a boring suggestion.
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?
@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!
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 tellI 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.
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."
Okay,
Here goes…
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
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
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.
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.
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.
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?