The mv command may generate spurious error messages when moving files from CEES local disk to sesfs.stanford.edu file shares.



Last revision January 29, 2013

The mv program changes the location of a file in the directory hierarchy. If the old and new locations are on the same disk or file share, the command simply changes the link between the directory name and the file inode. If the two locations are on different disks or shares, the command first copies the file to the new location and then removes the old copy.

The problem

When using mv to "move" a file from local disk on a CEES system to a file share from sesfs that is mounted on the CEES system, the command must make a copy on the file share from sesfs and then erase the original file from the local disk. In the process of making the copy, it attempts to set the permissions on the new file to match those on the original. But the original uses Linux style permissions, and the copy uses NTFS ACLs, so the mis-match between the two permission styles can cause mv to generate spurious error messages like these:

mv: preserving permissions for './samplefile': Operation not supported
mv: preserving ACL for './samplefile': Operation not supported
mv: preserving permissions for './samplefile': Permission denied

The file is correctly moved. The error messages are spurious.

Again, these spurious messages only occur when moving a file from local disk on the CEES system to an sesfs file share. They do not occur when moving files between directories that are both on the local disks, or between directories that are both on the file share, or between a directory on the file share and one on the local disk.

The workaround

You can simply ignore the error messages. The file is moved.

If you are using a script and don't want these error messages included in your output file, you can avoid them by explicitly performing the copy and erase functions, rather than letting mv do them for you implicitly. This works because the cp command accepts the default permissions settings of the sesfs file share for the new copy and does not try to force them to match the old file's settings. For example, use the cp and rm commands in sequence, like this:

cp /localdisk/samplefile /data/sesfs/myshare/samplefile
rm /localdisk/samplefile

Return to the list of known problems and workarounds.

Comments or Questions?