Permissions problems between HP-UX servers

[Raymond E. Lilly]

I have a large number of files on an older 11i v1 L-Class (PA-RISK) box that I want to copy over to a new 11i v3 RX (Itanium) box. After running into a few problems with permissions I created a copy of the files I want to move, used chmod -R user1:group1 to get a clean set of files, and exported the file system where they are located. On the new server, I created the exact user1:group1, mounted the filesystem and tried to cp -R the files to the new server. I started getting the infamous "Permission denied" on a bunch of files. As user1 on the old server I can open these files with pg. As user1 on the new system I can not. What am I doing wrong?

[Dennis Handly]

>I created the exact user1:group1,

I assume you used the same numeric IDs?
As user1 (or root), try the id(1) command on both.

[Mark McDonald_2]

As Dennis said, are the id's identical?

What does a ll show on the new server? Does it show user1 or a different number or user?

Try running the chmod command again on the new server.

[James R. Ferguson]

Hi:

When you do your recursive 'chown' are you running as root? If not, you may have subordinate directories with overly restrictive permissions that are blocking access to the files therein.

Regards!

...JRF...

[Raymond E. Lilly]

The initial problem that started all this fun is that my root account on the new machine doesn't have the same access on these files over the mounted file system as root directly on the old server. I thought root=root, bin=bin, etc for the standard system accounts (uid:gid are the same). Should root on the new server have the same rights to these files as root on the old server? If not, how can I get these ~100K files moved across without trashing the file permissions? (already tried a tar ball with no success and guess fbackup/frecover would fail as well).

Thanks for all the suggestions!

[Patrick Wallek]

root can **always** access all files locally on a server. There is no way I know of to prevent root from accessing any files.

The key in the above statement is "files locally on a server." The root user can have issues accessing files on NFS mounts if the directory was exported on the remote machine without allowing root access.

Are all of the files you are copying in local file systems or are there some from NFS mounted file systems?

[Raymond E. Lilly]

**All** the files are being copied across an NFS exported on the old server and mounted on the new server. The old server is 11i v1 so I used exportfs. The new server is 11i v3 and I used the smh to mount the NFS. I have to look at the export options available in sam on the old server to see if I can export the NFS with greater rights for the remote root user. Up to now I had added an entry in /etc/exports (/qad -access=newserver) and exportfs (# exportfs -auv).

[Patrick Wallek]

You need to modify the /etc/exports and use the '-root' option instead of -access on the 11.11 server.

The new line should look like:

/qad -root=newserver

Once you make that modification do a:

exportfs -va

I don't know if you would need to unmount and remount on newserver or not, but it can't hurt.

[Patrick Wallek]

Note: 'man 4 exports' will further explain the differences between -access and -root.

[Dennis Handly]

>Should root on the new server have the same rights to these files as root on the old server?

No, you have exported it as root is nobody.

>already tried a tar ball with no success and guess fbackup/frecover would fail as well).

Why would tar/pax fail?
root should be able to pax them up on the source machine and put it in a read only part of the exported filesystem. Then root on the client should be able to unpax them there to a local filesystem.

[Raymond E. Lilly]

Thanks everyone! Exporting with â root is a workable solution. I can now manage the files on both sides of the NFS as needed. Iâ ll have to block system access to the new server during the migration to avoid anyone causing mischief. Since the user list on the new server will not be an exact match of the old, Iâ ll probably need to loop through all the files and chown any exceptions after moving the files. Once this is done I will also revisit the problems encountered with tar. My guess is the problems are related to uid:gid mismatches that would need to be corrected before extracting the tar. Updates to followâ ¦

[Dennis Handly]

>Since the user list on the new server will not be an exact match of the old,

Why not? The user IDs should match across your whole (logical) organization.
(The list of allowed users don't have to match but the IDs should.)

[Raymond E. Lilly]

The solution was as Patrick suggested:
qad -root=newserver
exportfs -va

Thanks everyone.