https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1152 Lustre <p>mount lustre on /mnt<br/> ls /mnt (works)<br/> cd /mnt/blah (works)<br/> ls<br/> ls: cannot open directory .: Permission denied<br/> ls foo (works)<br/> ls /mnt/blah (fails)<br/> ls /mnt/blah/foo (works)</p> <p>Running strace on ls, I get permission denied opening '.', regardless of directory permissions.</p> Client: 1.8.7-wc1, 2.6.32-131.12.1.el6.x68_64<br/> Server: 1.8.4 LU-1152

ls: cannot open directory .: Permission denied

Bug Major Resolved Fixed Zhenyu Xu Ben Evans Wed, 29 Feb 2012 14:10:57 +0000 Tue, 3 Apr 2012 14:21:55 +0000 Tue, 3 Apr 2012 14:21:55 +0000 Lustre 1.8.7 0 5 <p>The user and group id's must be known the MDS, is the user in the MDS password files? Check the client and MDS system logs for errors. </p> <p>The user was root. I can run on an older Lustre/FS combo and it works. </p> <p>I can do the following and it still fails:</p> <p>mkdir /mnt/tmp<br/> cd /mnt/tmp<br/> ls</p> <p>sorry, I should clarify, an older Lustre Client/kernel version combo works fine.</p> <p>also, in addition:</p> <p>touch /mnt/tmp/foo<br/> ls /mnt/tmp/foo</p> <p>does work. I'm thinking there's some special handling of '.' that's causing an issue that I'm running into.</p> <p>Bobi</p> <p>Could you please comment on this one?</p> <p>Thanks</p> <p>Peter</p> <p>what's the output of "ls -l /mnt/"?</p> <p>ls -l /mnt displays everything correctly, but it is the only thing that does.</p> <p>what's the permission/acl output of /mnt/blah ?</p> <p>drwxrwxrwx (I've tried many permutations around that theme, none work)</p> <p>Would you mind enabling all debug message level "lctl set_param debug=-1" on client and servers, and collecting debug logs (client node as well as MDS server) during these operations? So that we can check out what the problem might be.</p> <p>Process for the dump:</p> <p>mount client<br/> start debugging<br/> ls /mnt<br/> ls -l /mnt<br/> mkdir /mnt/testdir<br/> ls -l /mnt/testdir (failed)<br/> touch /mnt/testdir/testfile<br/> ls -l /mnt/testdir (failed)<br/> ls -l /mnt/testdir/testfile (success)<br/> rm /mnt/testdir/testfile<br/> rmdir /mnt/testdir (failed)<br/> chmod 777 /mnt/testdir<br/> rmdir /mnt/testdir (failed)</p> <p>client request testdir's xattr</p> <div class="panel" style="border-width: 1px;"><div class="panelContent"> <p>00000080:00200000:2:1330700770.421348:0:16553:0:(xattr.c:349:ll_getxattr()) VFS Op:inode=708444163/3303540295(ffff88010e00ed50), xattr security.selinux<br/> ...<br/> 00000002:00000001:2:1330700770.421799:0:16553:0:(mdc_request.c:367:mdc_xattr_common()) Process leaving via err_out (rc=18446744073709551555 : -61 : ffffffffffffffc3)<br/> <font color="blue">====&gt;ENODATA</font></p> </div></div> <p>new client(1.8.7) old server(1.8.4) syndrome, I am afraid you'd update your server.</p> <p>Would disabling selinux be a workaround for this problem?</p> <p>I think not, gotta use &gt;= 1.8.7 server if your client is 1.8.7.</p> <p>Since old MDS does not have the essential info (stripe info for client) as following MDS log shows.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ grep fsfilt_ldiskfs_get_md /tmp/logs/1152/dump.mds.out 00002000:00000040:21:1330696880.700393:0:12708:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866817: rc -61 00002000:00000040:9:1330696880.706343:0:12706:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112901473: rc -61 00002000:00000040:9:1330696880.707520:0:12710:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1114144769: rc -61 00002000:00000040:15:1330696880.712199:0:12714:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112899589: rc -61 00002000:00000040:17:1330696880.713367:0:12723:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1114275841: rc -61 00002000:00000040:19:1330696880.714589:0:31534:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112965121: rc -61 00002000:00000040:15:1330696880.715786:0:31557:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866819: rc -61 00002000:00000040:17:1330696880.716954:0:31555:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1113817091: rc -61 00002000:00000040:1:1330696880.718103:0:31536:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1113882625: rc -61 00002000:00000040:23:1330696880.720901:0:12707:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866822: rc -61 00002000:00000040:22:1330696880.722087:0:31556:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1113849857: rc -61 00002000:00000040:4:1330696939.175531:0:31531:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866817: rc -61 00002000:00000040:17:1330696943.714265:0:31561:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866817: rc -61 00002000:00000040:15:1330696943.715212:0:12720:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 00002000:00000040:7:1330696952.152840:0:12719:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444164: rc -61 00002000:00000040:7:1330696952.152854:0:12719:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 00002000:00000040:17:1330696957.721309:0:12711:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 00002000:00000040:3:1330696981.345390:0:12713:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 00002000:00000040:13:1330696991.321460:0:31535:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 00002000:00000040:17:1330697014.615160:0:31536:0:(fsfilt-ldiskfs.c:717:fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 708444163: rc -61 </pre> </div></div> <p>disabling selinux is a workaround, but not a fix.</p> <p>Since 1.8.7-wc1 clients work on older versions of Linux with the same filesystem, this looks like a kernel incompatibility, rather than a client/server issue (or one that Lustre aggravates).</p> <p>First, the selinux should be disabled.</p> <p>Secondly, for "fsfilt_ldiskfs_get_md()) error getting EA 4/lov from inode 1112866817: rc -61" such log, in the case that only 1 OST installed on the server, is it possible the EA(stripe info) be empty? Seems it is just a kind of warning/log message, not really error.</p> <p>Ben,</p> <p>Can you describe more info about the step? It's 1.8.4 Lustre server, and all server devices were formated with this 1.8.4 Lustre server? What Linux kernel version do these servers use? What steps did you take? Just mounted the Lustre system and "mkdir /mnt/testdir" and then "ls /mnt/testdir" failed?</p> <p>server kernel version is 2.6.18-194.3.1.0.1.el5 and Lustre 1.8.4<br/> Formatted with that kernel/Lustre version.<br/> 8 OSTs, default striping.</p> <p>Steps on the client are exactly as you describe, mount, mkdir, ls.</p> <p>Disabling selinux on the client fixed the ls issue.</p> <p>hmm, strangely, I have tried "SELINUX=enforcing" and "SELINUX=targeted", and cannot hit it. Anyway, Lustre should not work with selinux enabled.</p> <p>As per Terascala - this ticket can be closed</p> Development Epic client Rank 1|hzvh8n: Rank (Obsolete) 6442 Severity