[Gluster-users] Files losing permissions

[Maik Kulbe]

Hi,

I've just had a problem removing a directory with test files. I had an inaccessible folder which I could neither delete nor read on the client(both NFS and FUSE client). On the backend, the folder had completely 0'd permissions and the files showed the 0'd permissions with the sticky bit. I can't remove the folder on the client(it fails with 'directory not empty') but if I delete the empty files on the backend, it's gone. Is there any explanation for this?

I also found that this only happens, if I remove the folder recursivly over NFS. When I remove the files in the folder first there are no 0-size files on the backend and I can delete the directory with rmdir without any problem.

> Justin,
> What you are seeing are internal DHT linkfiles. They are zero byte files
> with mode 01000. Changing their mode forcefully in the backend to
> something else WILL render your files inaccessible from the mount point. I
> am assuming that you have seen these files only in the backend and not
> from the mount point And accessing/modifying files like this directly
> from the backend is very dangerous for your data, as explained in this
> very example.
> Avati
>
> On Thu, Aug 1, 2013 at 2:25 PM, Justin Dossey <jbd at podomatic.com> wrote:
>
> One thing I do see with the issue we're having is that the files which
> have lost their permissions have "bad" versions on multiple bricks.
>  Since the replica count is 2 for any given file, there should be only
> two copies of each, no?  
> For example, the file below has zero-length, zero-permission versions on
> uds06/brick2 and uds-07/brick2, but good versions on uds-05/brick1 and
> uds-06/brick1.
> FILE is
> /09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump
> uds-05 -rw-r--r-- 2 apache apache 2233 Jul 6 2008
> /export/brick1/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump
> uds-06 -rw-r--r-- 2 apache apache 2233 Jul 6 2008
> /export/brick1/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump
> uds-06 ---------T 2 apache apache 0 Jul 23 03:11
> /export/brick2/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump
> uds-07 ---------T 2 apache apache 0 Jul 23 03:11
> /export/brick2/vol1/09/38/1f/eastar/mail/entries/trash/2008-07-06T13_41_56-07_00.dump
> Is it acceptable for me to just delete the zero-length copies?
>
> On Thu, Aug 1, 2013 at 12:57 PM, Justin Dossey <jbd at podomatic.com>
> wrote:
>
> Do you know whether it's acceptable to modify permissions on the brick
> itself (as opposed to over NFS or via the fuse client)?  It seems that
> as long as I don't modify the xattrs, the permissions I set on files
> on the bricks are passed through.
>
> On Thu, Aug 1, 2013 at 12:32 PM, Joel Young <jdy at cryregarder.com>
> wrote:
>
> I am not seeing exactly that, but I am experiencing the permission
> for
> the root directory of a gluster volume reverting from a particular
> user.user to root.root ownership.  I have to periodically do a "cd
> /share; chown user.user . "
> On Thu, Aug 1, 2013 at 12:25 PM, Justin Dossey <jbd at podomatic.com>
> wrote:
> > Hi all,
> >
> > I have a relatively-new GlusterFS 3.3.2 4-node cluster in
> > distributed-replicated mode running in a production environment.
> >
> > After adding bricks from nodes 3 and 4 (which changed the cluster
> type from
> > simple replicated-2 to distributed-replicated-2), I've discovered
> that files
> > are randomly losing their permissions.  These are files that
> aren't being
> > accessed by our clients-- some of them haven't been touched for
> years.
> >
> > When I say "losing their permissions", I mean that regular files
> are going
> > from 0644 to 0000 or 1000.
> >
> > Since this is a real production issue, I run a parallel find
> process to
> > correct them every ten minutes.  It has corrected approximately
> 40,000 files
> > in the past 18 hours.
> >
> > Is anyone else seeing this kind of issue?  My searches have turned
> up
> > nothing so far.
> >
> > --
> > Justin Dossey
> > CTO, PodOmatic
> >
> >
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
> --
> Justin Dossey
> CTO, PodOmatic
>
> --
> Justin Dossey
> CTO, PodOmatic
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users