rjneilly Contributor.
Contributor.
2481 views

Copy/Move Files preserving all metadata

Hi,

Silly question, but how do I copy or move files on an OES11 sp1 NSS volume (source and destination are on the same server) in such a way that all the metadata and data structure is preserved? In particular I want to preserve ownership, trustee's, timestamps, and namespaces. Thus I cannot use for example a Windows client since it does not understand the Mac namespace among other things. If the data were on NetWare NSS volumes (as both source and destination) then I would use SCMT. But of course SCMT does not work with OES11. I tried using the Miggui tool, but it does not work either - it does not support the source and destination being on the same server.

My use case is that I want to move a user's homedirectory to a new volume (on either the same or a different server) and then create a junction from the original location to the new thus eliminating the two hassles of updating the user object homedirectory attribute in eDir and/or revising the shortcut/alias on their desktop (typically an OSX client).

Thanks,

Ron
Labels (2)
0 Likes
11 Replies
gleach1 Absent Member.
Absent Member.

Re: Copy/Move Files preserving all metadata

would doing the copy using consoleone or the nwcopy built into the novell client from a windows machine work perhaps?

I think using consoleone should preserve all the extra attributes and rights

if you tried miggui using the GUI, maybe try the command line version as i've found this seems to expose more options and detail to run it with

0 Likes
jmarton2 Absent Member.
Absent Member.

Re: Copy/Move Files preserving all metadata

rjneilly wrote:

> Silly question, but how do I copy or move files on an OES11 sp1 NSS
> volume (source and destination are on the same server) in such a way
> that all the metadata and data structure is preserved? In particular I
> want to preserve ownership, trustee's, timestamps, and namespaces.
> Thus I cannot use for example a Windows client since it does not
> understand the Mac namespace among other things. If the data were on
> NetWare NSS volumes (as both source and destination) then I would use
> SCMT. But of course SCMT does not work with OES11. I tried using the
> Miggui tool, but it does not work either - it does not support the
> source and destination being on the same server.


Maybe try the nwcopy command?

http://www.novell.com/documentation/linux_client/linuxclient20sp1/data/bag1ljp.html

--
Your world is on the move. http://www.novell.com/mobility/
We know what your world looks like. http://www.novell.com/yourworld/

Joe Marton Emeritus Knowledge Partner
0 Likes
Knowledge Partner
Knowledge Partner

Re: Copy/Move Files preserving all metadata

rjneilly;2284450 wrote:
.. I tried using the Miggui tool, but it does not work either - it does not support the source and destination being on the same server...

Hi Ron,

Hu? Not sure about official support... but I've done this numerous times (specifically: running migfiles -which is the command miggui uses to do the copy) on one and the same server to copy over data from one volume to the other. It's also the fastest method).

Another option can be to first set the extended attribute flag for NSS - xAttr in short (see Support | Backing up Extended Attributes Trustees Ownership Without SMS on Linux NSS Volumes), after setting it you can use the Linux built in copy command with the preserve option set (and any other options like doing a recursive copy). The rsync tool should also work, but never tested that in a scenario like this one.

Cheers,
Willem
0 Likes
Knowledge Partner
Knowledge Partner

Re: Copy/Move Files preserving all metadata

magic31;2284550 wrote:
...(specifically: running migfiles -which is the command miggui uses to do the copy) on one and the same server to copy over data from one volume to the other. It's also the fastest method...


As a sanity check, just ran a little test on an OES11sp1 server using the miggui. I can successfully configure the same source and destination server (all pointing it to the server miggui is running from) and select to consolidate the filesystem.

I've also checked the "Migration Tool Administration Guide" (quickscan), but did not see any limitation mentioned against doing a file system consolidation on the same server. So you have me wondering why/where you found that it is not supported?

Cheers,
Willem
0 Likes
rjneilly Contributor.
Contributor.

Re: Copy/Move Files preserving all metadata

Hi Willem,

Thanks for the sanity check. I just did one too and found that I am only partially insane ;-).

It works when I log in with the eDir admin account : I see and can select volumes and files on both the "source" and "target" sides of the file. However if I login with an account that is equivalent to admin then I do not see and cannot select volumes/dirs/files on the "Source" side. Weirdly though I can see and select volumes/dirs on the "Target" side. My non-admin (but admin equivalent) account also has effectively full (Supervisor) rights to all volumes on the server - not through trustee assignment but through eDir object right inheritance. So I am not sure why there is a difference between the admin account and the admin-equivalent account, but at least I know the tool can do what I want.

Thanks,

Ron
0 Likes
rjneilly Contributor.
Contributor.

Re: Copy/Move Files preserving all metadata

NWCopy : does not preserve ownership or namespace metadata
ConsoleOne : surely you wouldn't suggest a tool that has been deprecated and is no longer maintained?! /jk.
Commandline : hmmm. Well I am looking for something that can be used by techs that are raised on Windows and gui's. Also that means giving them access to the server shell (with root level access) 😞

Thanks,

Ron
0 Likes
rjneilly Contributor.
Contributor.

Re: Copy/Move Files preserving all metadata

Hi,

That looks promising. But I seem unable to correctly specify the target and source... I keep getting the error "Not a Novell File System Object". Here is what I have tried so far for the filespec:
nwcopy -f --source nkc_ssc/users:/adm/cms/plevinsen/.spotlight-v100 --target . -s
nwcopy -f --source HOME/Staff/plevinsen/.spotlight-v100 --target . -s
nwcopy -f --source HOME/Staff/plevinsen/.spotlight-v100 --target HOME_2/Staff_2/plevinsen/ -s
nwcopy -f --source HOME/Staff/PLevinsen/.Spotlight-V100 --target HOME_2/Staff_2/PLevinsen/ -s
nwcopy -f --source /media/nss/HOME/Staff/PLevinsen/.Spotlight-V100 --target /media/nss/HOME_2/Staff_2/PLevinsen/ -s
nwcopy -f --source HOME/Staff/PLevinsen/.Spotlight-V100 --target HOME_2/Staff_2/PLevinsen/ -s
nwcopy -f --source HOME:/Staff/PLevinsen/.Spotlight-V100 --target HOME_2:/Staff_2/PLevinsen/ -s
nwcopy -f --source HOME --target HOME_2 -s
nwcopy -f --source HOME --target HOME_2
nwcopy -f --source .n12_HOME.Servers.Services.UBCO.OUC:/Staff/PLevinsen/.Spotlight-V100 --target n12_HOME_2.Servers.Services.UBCO.OUC:/Staff_2/PLevinsen/ -s
nwcopy -f --source \\n12\HOME:/Staff/PLevinsen/.Spotlight-V100 --target \\n12\HOME_2\:/Staff_2/PLevinsen/ -s

Can you inform me as what nwcopy would like to see for the source and target filespec? I've tried logged in as root and as an eDir user with full rights.

Thanks,

Ron
0 Likes
Knowledge Partner
Knowledge Partner

Re: Copy/Move Files preserving all metadata

rjneilly;2284637 wrote:
...I just did one too and found that I am only partially insane ;-).


Thankfully yes! What would happen to the color (fun and variety) in the world if we were only 100% sane 😉

rjneilly;2284637 wrote:
It works when I log in with the eDir admin account : I see and can select volumes and files on both the "source" and "target" sides of the file. However if I login with an account that is equivalent to admin then I do not see and cannot select volumes/dirs/files on the "Source" side.


Have you LUMmified the other user for the target and source server (which in this case are the same)? If not, that would be the issue I think. By default the account used to install OES servers will be LUM enabled for the server you are configuring/installing OES services on. The other one isn't.

If you have that user LUM enabled, check if the OES server agrees with that by using the "id [username]" command on the server console.

Cheers,
Willem
0 Likes
rjneilly Contributor.
Contributor.

Re: Copy/Move Files preserving all metadata

All accounts I am testing with are LUMified and 'id' on the server is copacetic too, so that is not it. I thought that maybe it was some "bad info" in one of the miggui xml project files so I blew them all away (/var/opt/novell/migration/). Tried with the bad account - and it still failed. So I looked at the log file and found this bug reported there:

2013-09-27 12:28:37,718 ERROR - FILESYSTEM:volmount.rb:Command to mount source: ruby /opt/novell/migration/sbin/volmount.rb -s 0.1.2.3 -a "cn=badaccount,ou=x,o=y" -c Not Applicable -f "/var/opt/novell/migration/NewProj0/fs/mnt/source" -m -t OES20
2013-09-27 12:28:37,722 INFO - FILESYSTEM:volmount.rb:*****************Command output start**********************************
2013-09-27 12:28:37,722 INFO - FILESYSTEM:volmount.rb:Information: ldapsearch command executed as "ldapsearch -LLL -s sub -H ldaps://0.1.2.3 -x -D "cn=badaccount,ou=x,o=y" "(&(CN=n12_*)(objectClass=Volume))" linuxNCPMountPoint -W"
2013-09-27 12:28:37,722 INFO - FILESYSTEM:volmount.rb:/opt/novell/migration/sbin/volmount.rb:616: [BUG] Segmentation fault
2013-09-27 12:28:37,722 INFO - FILESYSTEM:volmount.rb:ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

Clearly the attempt to mount the volumes as sources is causing a segmentation fault - says so right there! But it has no problem with the exact same volumes as targets. Likely this is because the target is the local server and nothing special needs to be done to mount the target file systems since they are arleady mounted. But the source could be anything so it is going to try to identify and mount the source filesystems via that volmount.rb script.

I decided to try the offending command from the command-line to see if I could get better feedback on the error and to quickly/easily try different parameters. Right away I could see that the miggui was either not passing the password on the command-line or it was but was hiding it in the log file. Also it passes an incorrect type with the '-t OES20' parameter. It should be '-t OES2'. However looking at the volmount.rb script it turns out that it only tests for 'NW' / not 'NW'. Thus if you pass it '-t popo' it will still work just fine!

The long story made short is that I have no idea what is causing this bug. At one point I thought that it was an error in handling certain characters in the password, such as &. But that turned out to be a red herring. After a lot of password testing, eDir object rights futzing and filesystem trustee assignment poking I've come up with... "it is working now - no idea what was wrong earlier". Sigh I hate these kind of problems.

Cheers,

Ron
0 Likes
rjneilly Contributor.
Contributor.

Re: Copy/Move Files preserving all metadata

Great News Comrades! I figured it out.

The volmount.rb script does not like it if your password contains two $ in a row. It may also dislike two & in a row or other symbols that can be problematic in a shell.

Cheers,

Ron
0 Likes
Knowledge Partner
Knowledge Partner

Re: Copy/Move Files preserving all metadata

rjneilly;2285535 wrote:
Great News Comrades! I figured it out.

The volmount.rb script does not like it if your password contains two $ in a row. It may also dislike two & in a row or other symbols that can be problematic in a shell.

Cheers,

Ron


Hey Ron,

Good info & detective work there! Thanks for feeding it back here. I'll pass it on to my Novell contact to see if this is a known issue or a bug should be opened against it.

Thanks,
Willem
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.