Resolution: As Brian noted, and Haris alluded to, these strange dirs are chowned this way when a non-running glusterfs is mounted. When I started the gluster volume remotely, they immediately mounted, such that I had the same gluster volume mounted on both /gl and /gll (/gll was created so I could ignore the odd state of /gl for a while). I was able to umount the gluster vol from /gll and delete it normally. So now it seems to be working correctly. While this might be an edge case, I wonder if this might be detected and a relevant error emitted by the client (yes, easy for me to say..).. thanks. hjm On Thursday 22 March 2012 14:05:25 Brian Candler wrote: > On Thu, Mar 22, 2012 at 01:56:49PM -0700, Harry Mangalam wrote: > > Previous email had a typo in Subject line. > > What do you mean by "destroying" the mountpoint? > > I have seen those d??????????? entries before (not with gluster). > IIRC it's when a directory has 'read' but not 'execute' bits set. > > $ mkdir foo > $ chmod foo/bar > $ chmod 666 foo > $ ls -l foo > ls: cannot access foo/bar: Permission denied > total 0 > -????????? ? ? ? ? ? bar -- Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine [ZOT 2225] / 92697 Google Voice Multiplexer: (949) 478-4487 415 South Circle View Dr, Irvine, CA, 92697 [shipping] MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120322/ef4de234/attachment.htm>
