The chown may affect access - possibly due to user ACE versus owner@ ACE behavior. A user ACE always refers to the specific user mentioned in the ACE. An owner@ ACE applies to the current owner of the file, which changes with chown.
owner@ represents the typical, expected behavior on UNIX but can produce confusing results on Windows. Alan On 12/17/10 1:24 AM, artiepen wrote:
I'm using zfs/osol snv_134. I have 2 zfs volumes: /zpool1/test/share1 and /zpool1/test/share2. share1 is using CIFS, share2: nfs. I've recently put a cronjob in place that changes the ownership of share2 to a user and a group, on the test filer every 5 minutes. The cron job actually runs in opensolaris on the storage unit. After a day or two, I started noticing that an application I have that lives on share1 will no longer open because it can't find its dll's. The only way to fix it is to reset the ownership of the entire subdir...from a Windows client. I don't even have to change it, just reset it. Security->Advanced->Owner->Replace owner on... Soon afterwards, I notice that the program doesn't work, for the same reason. I have to reset the permissions over and over again to get the application to load its dlls. I've also noticed that resetting the owner isn't the only thing that "fixes" it. I can also add, apply and remove the "Archive" attribute from Windows. It wasn't too long before I put 2 and 2 together and removed my cron job from crontab. Magically, the application, which lives on a completely different share, started working again without needing to be reset. Can anyone explain this bizarreness to me? Is there a reason or is it just a bug with this development version? Has it happened to anyone else?
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
