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? -- This message posted from opensolaris.org
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?
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of artiepen > > 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 share2to a> user and a group, on the test filer every 5 minutes. The cron job actuallyruns> in opensolaris on the storage unit.Wanna post your cron job? Most likely you just have an error in there ... Or there''s a softlink pointing from b to a ... or even hard link (which is less likely).
Sure, but it''s really straightforward: 0,5,10,15,20,25,30,35,40,45,50,55 * * * * chown -R user1:group1 /zpool1/test/share2/* 2> /dev/null ; chmod -R g+w /zpool1/test/share2/* 2> /dev/null Here''s the thing: There''s no way that it was a hard/soft link. I know what those are and I haven''t linked anything from those filesystems. When I was trying to troubleshoot this I discovered that on the system that was >mounting< the NFS share I could change the permissions at the mount point (which correlated to /share2) and it would mess up the CIFS share. Yes, setting permissions on the >mounting< system would cause the problem to happen. To clarify how odd that is: /zpool1/test/share2 is mounted on a web server at /mount/point. Going to /mount/point as root and chowning * caused the issue to happen with /zpool1/test/share1. This is reproducible, by the way. I can cause this to happen again, right now if I wanted to... Another thing: I checked the ownership and perms on /zpool1/test/share1. ls -dV showed no change in the ACLs than from what I had set. -- This message posted from opensolaris.org
To clarify how odd that is: /zpool1/test/share2 is mounted on a web server at /mount/point. Going to /mount/point as root and chowning * caused the issue to happen with /zpool1/test/share1. This is reproducible, by the way. I can cause this to happen again, right now if I wanted to... Another thing: I checked the ownership and perms on /zpool1/test/share1. ls -dV showed no change in the ACLs than from what I had set. -- This message posted from opensolaris.org
If it helps anyone who might see this in the future. I still haven''t figured it out. I ran a dependency checker on the application and even though >I< can browse the share that it''s located on, the application says that its dlls cannot be found even though they are in the same dir as the app. FWIW, the dependency checker application is called depends. Oddly enough, in this program, when the application isn''t available, it no longer lists it in the Recent menu... -- This message posted from opensolaris.org
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of artiepen > > Sure, but it''s really straightforward: > 0,5,10,15,20,25,30,35,40,45,50,55 * * * * chown -R user1:group1 > /zpool1/test/share2/* 2> /dev/null ; chmod -R g+w /zpool1/test/share2/* 2> > /dev/nullDo you have any spaces in the file/dir names under share2? Your command using the * will get expanded by the shell at runtime, instead of chown & chmod recursively descending into the share2 directory. I suggest the following instead: chown -R user1:group1 /zpool1/test/share2 2> /dev/null ; chmod -R g+w /zpool1/test/share2 2> /dev/null Also, get a really good idea of what you''re actually working on: echo /zpool1/test/share2/* And don''t assume there are no symlinks. Test it: find /zpool1/test/share2 -type l And look to see if any filesystem is mounted as a subdirectory of the other filesystem. zfs list | grep zpool1/test/share2 | grep -v @> To clarify how odd that is: /zpool1/test/share2 is mounted on a web serverat> /mount/point. Going to /mount/point as root and chowning * caused the > issue to happen with /zpool1/test/share1.If the web server is a NFS client, you should consider whether or not any previous mount/unmount request may have been at fault. Such as lazy dismount or forced dismount, and stuff like that. To be really sure, you could reboot the NFS client, which would guarantee no stale mounts lingering around.> This is reproducible, by the way. I can cause this to happen again, rightnow if> I wanted to...Could you show the output of "ls -ld" on some file or directory, to show the before and after?