[Gluster-users] Files losing permissions

[Anand Avati]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130801/4c1cac97/attachment.html>