> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@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/null
Do 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 server at > /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, right now if > I wanted to... Could you show the output of "ls -ld" on some file or directory, to show the before and after? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
