[LU-15579] When nfs exports lustre, chmod the strip directory under the strip directory will have a Permission Deny occurs error

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.12.4

Epic/Theme

client mds

• Severity: 3

Epic

client server

• Assignee: WC Triage
• Reporter: Jiahao Li

Description

 

nfs server(lustre client)：

# lfs getdirstripe test
lmv_stripe_count: 8 lmv_stripe_offset: 0 lmv_hash_type: fnv_1a_64
mdtidx           FID[seq:oid:ver]
     0           [0x200000400:0xe:0x0]
     1           [0x7c0000407:0xe:0x0]
     2           [0x280000405:0xe:0x0]
     3           [0x240000405:0xe:0x0]
     4           [0x340000403:0xe:0x0]
     5           [0x2c0000405:0xe:0x0]
     6           [0x380000404:0xe:0x0]
     7           [0x300000403:0xe:0x0] 

# cd test
# ls
debug
# lfs getdirstripe debug
lmv_stripe_count: 8 lmv_stripe_offset: 0 lmv_hash_type: fnv_1a_64
mdtidx           FID[seq:oid:ver]
     0           [0x200000bd0:0x4:0x0]
     1           [0x7c0000bd1:0x4:0x0]
     2           [0x280000bd1:0x4:0x0]
     3           [0x240000bd1:0x4:0x0]
     4           [0x340000bd1:0x4:0x0]
     5           [0x2c0000bd2:0x4:0x0]
     6           [0x380000bd1:0x4:0x0]
     7           [0x300000bd1:0x4:0x0]

nfs client:

 

# cd /mnt/nfs3/test
# ls
debug
# chmod 755 debug
# ls
ls: cannot access debug: Permission denied
ls: reading directory .: Permission denied
debug
# ls
ls: reading directory .: Permission denied

 

When I execute ls in the directory of the nfs server, the nfs client ls can return to normal

nfs server(lustre client)：

 

# pwd
/muzitest/test
# ls
debug

nfs client:

# ls
debug 

I tried to check on the nfs server (lustre client) and found that the parent_fid in ll_dir_get_parent_fid was incorrectly obtained. This function should correctly obtain the fid of the parent directory of debug, but it lacked the fid of debug itself.

Therefore, I started to investigate the code on the server side and found that the step to return the debug directory fid is in the mdt_raw_lookup function:

The mdo_lookup call chain is as follows:

 

mdt_raw_lookup --> mdd_lookup --> dio_lookup --> lod_lookup --> osd_index_ea_lookup --> osd_ea_lookup_rec

In the osd_ea_lookup_rec function, I found that the fid is obtained in the osd_get_fid_from_dentry function, and the content of struct ldiskfs_dir_entry_2 *de is filled in osd_ldiskfs_find_entry. But I can't find the code related to osd_ldiskfs_find_entry in the source code, so I can't analyze it further.

Issue Links

• is related to: LU-15388 Wrong dotdot FID parameter for osd_add_dot_dotdot()

Comments

[Jiahao Li]

The problem was completely solved when I used LU-14826 to adapt the 2.12.4 version of lustre.

Thanks for everyone's help

[Jiahao Li]

Recently in use, I found that it is normal for nfs to export if the path is all striped directories. If the path is single strip -> single strip -> single strip, it will be chmod on the last directory. Trigger the problem of permission deny. This is not appearing before using LU-15388

[Jiahao Li]

Thanks for the help, after I patched the code according to LU-15388, the problem was solved. It is true that the directory needs to be recreated. After the old directory is chmoded, there will still be Permission Deny.

[Jiahao Li]

I am doing patch adaptation, I will synchronize the final result in time, thank you for your help

[Andreas Dilger]

This may relate to LU-15388. Could you please test the patch linked to that ticket. Note that you will need to create a new directory in that case so that the parent FID is set correctly.

[Lai Siyao]

This looks to be a duplicate of LU-14826.