• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6142
  • Last Modified:

mv: 0653-404 Unable to duplicate owner and mode after move.

Hi,

We are having some very strange issues trying to move files across different directories in our UNIX file system.

The error we are getting in our AIX 7.x unix shell is:

mv: 0653-404 Unable to duplicate owner and mode after move.

Open in new window


Basically we are trying to move a file from one directory to another, on the same box/file system.

The file is being moved from:
drwxrwxrwx    2 prosvr   usr             256 Sep 20 14:59 man

Into:
drwxrwxrwx    2 prosvr   usr             256 Sep 20 14:59 truck-in

File attributes:
-rw-rw-rw-    1 prosvr   usr             147 Sep 20 14:25 floor-out.l1350945

The user moving the file is: prosvra


# lsuser prosvra
prosvra id=566 pgrp=usr groups=usr,nossh home=/home/prosvra shell=/usr/bin/ksh gecos=PROGRESS ASYNC SERVERS login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=

The owner of the file/folders is:


# lsuser prosvr
prosvr id=565 pgrp=usr groups=usr,nossh home=/home/prosvr shell=/usr/bin/ksh gecos=PROGRESS SERVERS login=true su=true rlogin=true daemon=true admin=true sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=


(notice they are two different users, prosvr and prosvra).

Why do I get that error with the "mv" command? I can suppress it by issuing a -I parameter to ignore ACL conversion errors but I would like to fix the issue rather than suppressing it.

The file gets moved sucesfully, but we still get the error that some permissions were not able to be converted?

Any help would be appreciated as I am a little confused, since source and destination directories have been chmnoded to 777.
0
mirde
Asked:
mirde
  • 5
  • 3
1 Solution
 
mirdeAuthor Commented:
I should also add, the file is coming from a NTFS file-system being transferred to the box using API calls and as a BLOB data type.
0
 
woolmilkporcCommented:
Hi,

I assume that you're moving between filesystems.

I such a case mv first copies the file and then deletes the original.
Only root would be allowed to modfy the ownership of the copied file back to the one of the original file (prosvr).
Since you're not root the destination file will be owned by the user who moved it (prosvra).

That's basically what the message is telling you.

wmp

0
 
mirdeAuthor Commented:
Hi Woolmilkporc,

The file is on the same box, but it is moving between different Filesystems (mount points).


Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           0.75      0.53   30%    10621     8% /
/dev/hd2           7.50      5.57   26%    47761     4% /usr
/dev/hd9var        8.00      7.33    9%     7064     1% /var
/dev/hd3           0.12      0.11   11%     2059     7% /tmp
/dev/fwdump        1.00      0.96    4%       10     1% /var/adm/ras/platform
/dev/hd1          40.00     29.92   26%    43996     1% /home
/dev/hd11admin      0.12      0.12    1%        5     1% /admin
/proc                 -         -    -         -     -  /proc
/dev/hd10opt       5.00      4.38   13%    14794     2% /opt
/dev/livedump      0.25      0.25    1%        4     1% /var/adm/ras/livedump
/dev/lv_usr1     199.75    128.07   36%   431191     2% /usr1
/dev/lv_usr2     271.75    252.64    8%    62391     1% /usr2
/dev/lv_usr3     499.75    192.50   62%    41826     1% /usr3
/dev/lv_usr4     499.75    208.37   59%    37755     1% /usr4
/dev/lv_usr1_dbs    399.75    219.52   46%       84     1% /usr1/dbs
/dev/lv_usr1_ai     49.75     49.53    1%       39     1% /usr1/ai_files
/dev/lv_usr1_bi     49.75     46.22    8%       13     1% /usr1/bi_files
/dev/lv_usr1_backup    199.75     76.63   62%       87     1% /usr1/db_backups


From /home to /usr3, but the file system type remains the same.

So this message is then safe to ignore, since we know that the process that moves the file to the AIX box is the prosvr user, then another process running under prosvra moves the file.

This error is then safe to suppress with mv -I switch? I just did not want to suppress a message for which there could be pending hell to be unleashed. until i fully understand what it is we are suppressing.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
mirdeAuthor Commented:
Is there a way to allow prosrva to change ownership without being root on these files?
0
 
woolmilkporcCommented:
No way. Only root can do that, for security resons.
0
 
woolmilkporcCommented:
>> until i fully understand what it is we are suppressing. <<

If you're aware that the owner of the file will change from the file's creator (prosvr)
to the file's "mover" (prosvra) and if you can tolerate this (seems you do) you can suppress the message safely, of course.

The only other way to get rid of the message is to acquire (temporarily) root privileges the one way or the other.

"sudo" could be an option. sudo for AIX is here:
http://www.perzl.org/aix/index.php?n=Main.Sudo

Should you decide to use sudo and have questions about its installation and/or use, please let me know!

wmp
0
 
mirdeAuthor Commented:
Thanks woolmilkporn, as a workaround between this, we implemented in our code to sudo chown the file, and ensured the user running sudo is in the sudoers file; all working good.

Thanks for your help.
0
 
mirdeAuthor Commented:
Using sudo to chown file in the code worked for us.
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now