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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://supercolony.gluster.org/mailman/listinfo/gluster-users -- Justin Dossey CTO, PodOmatic -- Justin Dossey CTO, PodOmatic _______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
