BUG: move disk gives OK with errors

lince

Member
Apr 10, 2015
78
3
8
Hello,

Not sure if this is a bug or not, I will explain what happens.

When I move a disk, I get "TASK OK" message but there are some errors in the process. I moved the disk for a template from nfs to nfs.

Maybe the task has completed correctly but I would expect a "TASK WARNINGS" to notify that there were some errors in the process.

This is the output:

transferred: 10678362439 bytes remaining: 59055801 bytes total: 10737418240 bytes progression: 99.45 %
transferred: 10737418240 bytes remaining: 0 bytes total: 10737418240 bytes progression: 100.00 %
transferred: 10737418240 bytes remaining: 0 bytes total: 10737418240 bytes progression: 100.00 %
/usr/bin/chattr: Inappropriate ioctl for device while reading flags on /mnt/pve/nfs-ssd/images/152/base-152-disk-1.qcow2
command '/usr/bin/chattr -i /mnt/pve/nfs-ssd/images/152/base-152-disk-1.qcow2' failed: exit code 1
TASK OK

Just wanted to let you know.

Thanks.
 
this just says that the chattr +i command fails (for whatever reason)
while this is not optimal, it should not affect operation in any way (as long as no one messes with this file)
 
Hello,

I know that it should not affect operation. That is why I would expect a warning (instead of an error).
 
Hi @dcsapak,

sorry to necrobump this thread, but I thought to ask my question here in the top google result. I also have this error in front of me right now on a new company proxmox cluster with a NFS datastore from a netapp storage system.

Can you elaborate on the technical ramifications if the underlying NFS mount does not support extended file attributes?

Thanks in advance
hasechris
 
setting the '+i' (immutable) flag is only a further protecting layer. It's set to prevent accidental modification of template base file (since it could have linked clones).
everything should continue to work even without that flag, but now an admin could modify that image without first removing that flag
 
setting the '+i' (immutable) flag is only a further protecting layer. It's set to prevent accidental modification of template base file (since it could have linked clones).
everything should continue to work even without that flag, but now an admin could modify that image without first removing that flag

ah thank you for the explanation. Yeah ok, now I understand why it is not super important, but also not completly irrelevant. This scenario is no problem in our case, also the error message only got shown once and subsequent disk moves did not trigger the error again.

Thanks
hasechris