Can anyone help? I have a cloned filesystem (/u05) from a snapshot of /u02. The owner/group of the clone is (oracle:dba). If I do oracle% cd /u05/app oracle% rm -rf R2DIR .. All the files in the R2DIR tree are removed, but none of the (sub)directories. If I run the same "rm -rf" as root, the directory tree itself is removed (ie. what I would expect) Any ideas? This message posted from opensolaris.org
Actually, just tried this on a non-cloned filesystem with the same results. I can''t believe there is a bug with "rm -rf", so is this something to do with ACLs ? Help! Tom This message posted from opensolaris.org
Just a thought -- unmount /u05 and check what ''ls -l /u05'' shows. If the permissions on the directory that you mount onto are wrong (not world-executable, should be 0755), rm -r (and many other commands) will fail in mysterious ways.... This message posted from opensolaris.org
I''m not at the machine to check at the moment, but I didn''t create the /u05 mountpoint manually. ZFS created it automatically when I did :- % zfs set mountpoint=/u05 zfspool/u05 You would hope that ZFS didn''t get the underlying permissions wrong! This message posted from opensolaris.org
I''m not at the machine to check at the moment, but I didn''t create the /u05 mountpoint manually. ZFS created it automatically when I did :- % zfs set mountpoint=/u05 zfspool/u05 You would hope that ZFS didn''t get the underlying permissions wrong! This message posted from opensolaris.org
Tom Simpson wrote:> Can anyone help? I have a cloned filesystem (/u05) from a snapshot of /u02. > > The owner/group of the clone is (oracle:dba). > > If I do > > oracle% cd /u05/app > oracle% rm -rf R2DIR >Are you sure you have adequate permissions to descend into and remove the subdirectories?> .. All the files in the R2DIR tree are removed, but none of the (sub)directories. If I run the same "rm -rf" as root, the directory tree itself is removed (ie. what I would expect) > > Any ideas? > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Tom Simpson wrote:> After I created the filesystem and moved all the data in, I did :- > > root% chown -R oracle:dba /u05All that does is change the owner/group of the files/directories. It doesn''t change the permissions of the directories and files. What are the permissions of the directories you are trying to delete? Can you gather some truss output from the "rm"? -Mark
Well, You''re spot on. Turns out that our datacentre boys change the umask of root to 0027. :-( This message posted from opensolaris.org
I''d filed 6452505 (zfs create should set permissions on underlying mountpoint) so that this shouldn''t cause problems in the future.... This message posted from opensolaris.org
Anton B. Rang wrote:>I''d filed 6452505 (zfs create should set permissions on underlying mountpoint) so that this shouldn''t cause problems in the future.... > >6238072 might also be of interest. Darren
Anton B. Rang wrote:> I''d filed 6452505 (zfs create should set permissions on underlying mountpoint) so that this shouldn''t cause problems in the future.... >Err.. the way you have described that, seems backward to me, and violates existing expected known solaris behaviour, not to mention logical separation of filesystems. zfs should not go changing the permissions on the [presumably] ufs directory underneath it. Yuck! how about, "operations on zfs filesystems should ignore permissions of the underlying mount point"? (although maybe this has to be "fixed" at the vfs level. But if so... Good! it''s only about 10 years overdue...)
On Thu, Aug 03, 2006 at 03:50:20PM -0700, Philip Brown wrote:> > Err.. the way you have described that, seems backward to me, and violates > existing expected known solaris behaviour, not to mention logical > separation of filesystems. > zfs should not go changing the permissions on the [presumably] ufs > directory underneath it. Yuck! >As with the existing code, this would only apply when ZFS was responsible for creating the mountpoint itself. The administrator could change the underlying permissions, or pre-create the directory and ZFS would not modify it. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
> Anton B. Rang wrote: > > I''d filed 6452505 (zfs create should set permissions on underlying mountpoint) so that this shouldn''t cause problems in the future.... > > Err.. the way you have described that, seems backward to me, and violates > existing expected known solaris behaviour, not to mention logical separation > of filesystems. > zfs should not go changing the permissions on the [presumably] ufs directory > underneath it. Yuck!Perhaps the way the synopsis is phrased is ambiguous, but I understood the issue to be with mountpoints that ZFS creates for you, not for existing mountpoints. At least that''s the example in the report.> how about, "operations on zfs filesystems should ignore permissions of the > underlying mount point"?As referred to in the synopsis: 4697677.> (although maybe this has to be "fixed" at the vfs level. But if so... Good! > it''s only about 10 years overdue...)True. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
On Thu, Aug 03, 2006 at 01:35:54AM -0700, Tom Simpson wrote:> Well, > > You''re spot on. Turns out that our datacentre boys change the umask of root to 0027. > > :-(Many years ago, back in the days of Solaris 2.5.1, changing root''s umask to 027 caused problems if you, say, restarted the automounter -- you couldn''t pwd inside filesystems automounted after the restart. That''s because automountd would mkdir() the mount-point, and it''d have the wrong permissions, so .. traversal would break. That .. traversal should care about the covered node''s permissions is a bug. Nico --