[LU-3826] copytool restore should set owner of volatile file before copy Created: 22/Aug/13  Updated: 14/Jan/14  Resolved: 30/Aug/13

Status: Closed
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.5.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: John Hammond Assignee: John Hammond
Resolution: Duplicate Votes: 0
Labels: HSM

Issue Links:
Related
is related to LU-4293 lfs_migrate is failing with a volatil... Resolved
Severity: 3
Rank (Obsolete): 9872

 Description   

HSM restore fails for files not owned by root since the copytool does not set the ownership of the volatile file and layout swap required that the two files have the same ownership.



 Comments   
Comment by Andreas Dilger [ 23/Aug/13 ]

The volatile file should be created by the MDS with the ownership of the original process as with any newly-created file, otherwise the non-root copytool will not have permission to chown() the file (nor should it be able to).

Comment by John Hammond [ 23/Aug/13 ]

Are we planning to support a non-root copytool? This is news to me. At very least it needs CAP_FOWNER, CAP_DAC_OVERRIDE and maybe some others.

By original process, do you mean the copytool?

Comment by John Hammond [ 27/Aug/13 ]

Please see http://review.whamcloud.com/7461.

Comment by John Hammond [ 30/Aug/13 ]

Folded into HSM timestamps and ownership issue LU-3811.

Generated at Sat Feb 10 01:37:14 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.