Hello Pranith, I believe the user generated the files using the Climate Data Operators (CDO) tools (https://code.zmaw.de/projects/cdo). If it would help, I will ask the user if there is an easy way to reproduce the problem, ideally without the need for a large and complicated input data set. Regards Dan. -- Mr. D.A. Bretherton Computer System Manager Environmental Systems Science Centre Harry Pitt Building 3 Earley Gate University of Reading Reading, RG6 6AL UK Tel. +44 118 378 5205 Fax: +44 118 378 6413 On 05/08/11 14:17, Pranith Kumar K wrote: > hi Dan, > We tried reproducing it in our local setup but the user > ownership/permissions are not changing when this situation is hit, > there must be some other reason why this would have happened. Could > you let us know what all operations were going on before it went into > this situation. > > Ignore this log, it is a misleading log that will be removed in > the future releases. > > Pranith > > On 08/04/2011 05:46 PM, Dan Bretherton wrote: >> Hello All- >> I have had a spate of these errors in one of my volumes recently, >> with GlusterFS version 3.2.2. >> >> [2011-08-02 16:14:38.211400] W [afr-open.c:624:afr_openfd_flush] >> 0-atmos-replicate-7: fd not open on any subvolume 0x2aaaaf51e174 >> (/users/rle/CMIP5/NCC/NorESM1-M/rcp45/r1i1p1/ua_6hrPlev_NorESM1-M_rcp45_r1i1p1_2182010100-2182123118.nc) >> >> >> The files have root ownership (which is not correct) but are >> otherwise intact. The errors occur when the files are being written >> and the problem is not restricted to one client or one server. I >> have seen this error in GlusterFS client logs and in nfs.log. I am >> not running any rebalance operations at the moment. >> >> Does anybody know what causes this or how to stop it? I hope I don't >> have to go back to doing "chown -R" in people's directories regularly >> to correct ownership problems. >> >> Regards >> Dan. >