NFS Server and Linux (Redhat) clients
Andrew Simms
testing NFS Server functionality.
One test involves an aging Linux server that has approximately 10TB of data
spread over many thousand files and a fairly deep directory structure. When
we attempt to copy files from the Linux server to a directory mounted from
our 2k8 server we are seeing several anomalies:
1. When using rsync to copy over a subset of the file structure, it will
encounter errors creating some directories, usually ones that are a couple
levels deep. There does not seem to be any issue creating top and first
level directories, and these directories have the same ownership/permissions
as the ones it is having difficulty making.
2. If we use a program like robocopy on the windows side to pull files
over, they are copied but all UNIX permission information is lost (despite
using /COPYALL). In fact, an ls -l shows files as having chmod permissions of
000.
3. We were having some issues with some poorly named files (i.e. they
contained colons (":")), we tried the mapping functionality to map ":" to
other characters. This doesn't seem to work reliably at all--mapping to
something like "-" caused clients to see a "?", and things really got goofy
if tried something like a "." period--basically doing an ls would show ? and
?? (for . and ..). We have stopped using this and will fix our filenames.
This feature seems like a total hack.
4. Files in the root group (i.e. gid = 0) seem to get set to nfsnobody
despite there being a mapping entry in AD.
5. We have seen issues when the Linux client is running as root, despite
having checked the "root access" checkbox. It appears that root does not
have full root privilege, perhaps this is related to #4.
Have others encounterd these types of issues? I'm hoping these are
configuration problems on our end rather than flaws in the MSFT NFS
implementation. It will really set back plans to move more towards Windows
if we don't have a solid NFS Server on w2k8.
Thanks,
--Andrew
Ashish
> encounter errors creating some directories, usually ones that are a couple
> levels deep. There does not seem to be any issue creating top and first
> level directories, and these directories have the same ownership/permissions
> as the ones it is having difficulty making.
There a hot fix for W2K8 NFS Server where it doesn't handle access
bits correctly when dealing with folder hierarchy that's a little
deep. Install that and see if that helps.
>
> 2. If we use a program like robocopy on the windows side to pull files
> over, they are copied but all UNIX permission information is lost (despite
> using /COPYALL). In fact, an ls -l shows files as having chmod permissions of
> 000.
rsync should be used when transferring files from a *nix box to
Windows box so that the permissions/ownership information can be
retained. The requirement is that all users and grous should be mapped
to their Windows counterparts first. Do you have UID/GID assigned to
the in AD?
> 3. We were having some issues with some poorly named files (i.e. they
> contained colons (":")), we tried the mapping functionality to map ":" to
> other characters. This doesn't seem to work reliably at all--mapping to
> something like "-" caused clients to see a "?", and things really got goofy
> if tried something like a "." period--basically doing an ls would show ? and
> ?? (for . and ..). We have stopped using this and will fix our filenames.
> This feature seems like a total hack.
You can use a character translation file so that the character that
are illegal on NTFS can be converted to legal ones while being created
and at the same time, *nix clients can access them using the original
files name. Installing the latest fix for NFS will take care of a bug
in this area and it will work just fine.
>
> 4. Files in the root group (i.e. gid = 0) seem to get set to nfsnobody
> despite there being a mapping entry in AD.
What is this entry in AD? Is this a user called root? Or, you have
assigned UID 0 to the Administrator user.
>
> 5. We have seen issues when the Linux client is running as root, despite
> having checked the "root access" checkbox. It appears that root does not
> have full root privilege, perhaps this is related to #4.
Whoever bears the UID 0 should also be in the Domain Admins groups and
unlike *nix, it has to be present on the ACLs of the files/folders on
the folder being shared over NFS. If you use KeepInheritance, adding
this user to the top level will also propagate it to the downlevel
files/folders.
I am sure you will have more questions on the above. Feel free to let
me know if something is not clear.
- Ashish