Dan Bretherton <d.a.bretherton at reading.ac.uk> writes: > Hello Rajesh- Here are the permissions. The path in question is a > directory. > > [sms05dab at jupiter ~]$ ls -ld /users/gcs/WORK/ORCA1/ORCA1-R07-MEAN/Ctl > drwxr-xr-x 60 vq901510 nemo 110592 Feb 23 04:37 > /users/gcs/WORK/ORCA1/ORCA1-R07-MEAN/Ctl [sms05dab at jupiter ~]$ ls -ld > /users/gcs/WORK/ORCA1/ORCA1-R07-MEAN lrwxrwxrwx 1 gcs nemo 49 Feb 1 > 2012 /users/gcs/WORK/ORCA1/ORCA1-R07-MEAN -> > /data/pegasus/users/gcs/WORK/ORCA1/ORCA1-R07-MEAN [sms05dab at jupiter > ~]$ ls -ld /data/pegasus/users/gcs/WORK/ORCA1/ORCA1-R07-MEAN > drwxr-xr-x 27 gcs nemo 99210 Feb 23 03:14 > /data/pegasus/users/gcs/WORK/ORCA1/ORCA1-R07-MEAN > > As you can see the parent directory in this case was a symlink but > that's not significant. I ran the "ls -l" commands using my account - > sms05dab, but the problem was originally reported by user vq901510. > until I did "ls -l" as root neither of us could access the directory, > because the parent directory was owned by user gcs. Usually the > problem is related to ownership of the file or directory itself. This > is the first time I have seen the I/O error caused by parent directory > permissions. > > This problem seems to have started following an add-brick operation a > few weeks ago, after which I started "gluster volume rebalance > <VOLNAME> fix-layout" (which is still running). It occurred to me that > the problem could be related to link files, many of which need to be > rewritten following add-brick operations. This could explain why the > ownership of the parent directory is significant, because users > sms05dab and vq901510 don't have permission to write in the parent > directory owned by user gcs. Normally this wouldn't be a problem > because only read access to other users' data is required, but it > appears as though read access was being denied because the new link > file couldn't be written by unprivileged users. Is this a plausible > explanation of the I/O error do you think? This sounds like my recent bug: https://bugzilla.redhat.com/show_bug.cgi?id=913699 In the bug, I said that writing on the fuse mount of one of the brick servers fixed the problem.... but those were the only hosts I was attempting access as root. -- Shawn Nock (OpenPGP: 0x65118FA5) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130225/0e771873/attachment.sig>
