NFS on a NTFS volume

[VAN_CLEEF]

(Newbie to NetApp, so forgive me if I get the terminology backwards.)

We are trying to migrate our existing data from a couple of non-NetApp file servers to a new netapp unit.  The volumes are setup with NTFS as primary (i.e. Windows ACLs always win) with NFS exports.  Our engineers live on NFS, while managers and support staff all live on windows.   We've copied the password file to the server to implement UID mapping and gave root access rights to one of our Unix servers.

/vol/pal0fs02_vol2/User -sec=sys,rw,root=10.10.10.10

My problem is copying the data and getting the permissions correct.  

• Robocopy is running on the primary volume, but it is very, very slow for some reason.  However, all files copied before UID mapping was initiated are listed as owned by root on the NFS side.  Newer files are listed correctly, but we can't change the older ones. Permissions "work" correctly, but they don't "look" correct.
• Using "rsync" on the unix side, things run a lot faster. The UID/GID is set to zero. Again, permissions appear to be working correctly, based on the CIFS ACLs. However, all files are shown owned by root, as the 'chown' fails.

There simply doesn't seem to be away to fix this.  Especially, for the user home directories.  What I would love is a way to run a one time script, after all the copying is done, to perform an rsync verification of the copy and change the UID/GID to match the original file.

It really seems to me that this should be an easy thing to fix, but being new to this beast I keep going in circles.  I need the NTFS side to work correctly as AD access groups are used intensively by managers and automatic tools to manage access permissions.  However, I need to keep the engineers happy and productive at the same time.

Can this be done?

[VAN_CLEEF]

Here is another example of the problem.  Attempting to copy a user's home directory from the old system to a newly created home directory --- created via windows with all the correct permissions on that side and show as owned by the user under NFS.  The user owns the target directory, but we still get permission denied.  I get the same error if I run the rsync as root.

sudo -u user1 rsync -rlptogv --numeric-ids /hosts/oldsystem/home/user1/ /hosts/newsystem/home/user1/

sending incremental file list

rsync: ERROR: cannot stat destination "/hosts/newhost/home/user1/": Permission denied (13)

rsync error: errors selecting input/output files, dirs (code 3) at main.c(554) [receiver=3.0.6]

rsync: connection unexpectedly closed (9 bytes received so far) [sender]

rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

# ls -la /hosts/newhost/home/user1/

total 12

drwx------  2 user1 group1  4096 Feb  7 22:38 .

drwx------ 84 root    root 8192 Feb  8 07:09 ..

#

Is there any way to change the permission structure to standard NFS long enough to complete this copy.... and then change it back to windows mode?

[HENRYPAN2]

Bob,

You may wish to double check your firmware, AD & other security setting to see whether they also allow you to run the copy.

Good luck

Henry

[billshaffer]

Robert:

The problem is that you're trying to use unix tools to view and replicate windows ACLs - I'm not aware of anything that'll do that, unless maybe you mount the volume as a cifs share.  You say that NTFS permissions mean that "Windows ACLs always win,", which isn't really right.  Windows ACLs are applied; there is nothing to win or lose, as the only ACLs are windows'.

The volume is NTFS, which means that NTFS permissions are in force.  NFS doesn't know anything about those; the ACLs you see on the NFS mount are unreliable as far as determining ownership and rights, and trying to use rsync to copy the ACLs will fail, because rsync only sees the ACLs NFS shows.  The only reason that the owner shows up after you set up user mapping is because the filer now has something to map the user to, where before it didn't.  Again, seeing the owner on the unix side doesn't necessarily mean that is the owner on the windows side.

Hope this helps...

Bill

This is also why your second example is failing - you've given root access to the NFS share, but not necessarily to the NTFS data within it.

Is there any way to change the permission structure to standard NFS long enough to complete this copy.... and then change it back to windows mode?

Technicall, yes, you can set the volume to unix permissions, copy the data, then set it back to NTFS, but you'd still face the same problem copying, as NFS won't recognize the source NTFS ACLs, and converting to NTFS blows away any unix ACLs (pretty sure on that, anyway).

Your best bet is going to be using a windows based copy tool (e.g., Robocopy) - that way you know you're replicating the ACLs.  The permissions won't look right on unix; in my experience there is really no way around this.  As long as your usermaps are set up right, unix IDs will map to windows IDs and all the AD access group stuff should work fine.  I've primarily worried about the opposite - mapping windows users to unix ACLs - but my understanding is that the reverse should work fine..