Unsolved
This post is more than 5 years old
7 Posts
0
3086
February 13th, 2013 13:00
Windows access to NFS / CIFS share
We have a share that we need to export via NFS to a windows serve 2008R2 client. The share is already exported via CIFS to other clients but the new client is not in the domain hence the use of NFS. Usually I would use windows drive mappings to connect via cifs and provide username / password via the mount, however I need this to be mapped and available before any users login (it will be a folder for use on the server which is acting as an ftp server).
I have managed to get the export visible and mounted using windows nfs client services and the majority of files are readable but write is not possible. I've checked the rw and access export options and these look OK so I am thinking it is something to do with the user mapping. I don't want to mess with the usermapper service on the Celerra as it will affect the CIFS users.
Without making any changes on the windows side the NFS properties were showing as GID / UID of 32770. I added the anonymousgid/uid registry keys (Set to 0) to the windows server and this is reflected in the mount but I still get access denied.
We have no unix users to map anything to and this is the only NFS export at the moment.
I'm sure I'm missing something simple but I'm not sure what. I've tried reading the multiprotocol docs but am even more confused.
Can anyone shed any light on this?
System is a Celerra NX4
Thanks
Rainer_EMC
4 Operator
•
8.6K Posts
0
February 14th, 2013 02:00
What access policy do you use?
Have you explicitly disabled usermapper ?
The accounts you are using on the Windows server – are they local accounts / groups ?
Rainer
afrench2
7 Posts
0
February 14th, 2013 03:00
I am using native access for the filesystem
Usermapper is enabled as I believe it is needed for the other production CIFS shares
I have tried the mount with AD usernames (from the domain the CIFs server is registered to) and without any username. The result is the same
Thanks
Alastair
Rainer_EMC
4 Operator
•
8.6K Posts
0
February 14th, 2013 04:00
We it looks like you got an automatic mapping for your account – 32770 is the first ID that usermapper would use.
You can check with server_cifssupport
When testing don’t forget there is a persistent secmap – if you change mapping then you need to clear the secmap first – otherwise you are likely to test with old info.
Anyway for NATIVE access policy with default params only the Unix access rights should matter in determing whether you have access.
What does an ls –l says for the files that you cannot write to ?
Rainer
afrench2
7 Posts
0
February 14th, 2013 05:00
server_cifssupport server_2 -secmap -list shows that the uid of 32770 is mapped to my AD account and the same gid is mapped to Domain Users. This makes sense as I was the first to access the CIFs share when it was created.
Will clearing secmap affect any users using other CIFs shares on the same CIFs server?
How can I run an ls -s, I don't have any Unix hosts to connect to the export? I can ssh to the control station but I can't find where the filesystem is located?
Alastair
Rainer_EMC
4 Operator
•
8.6K Posts
0
February 14th, 2013 07:00
Just install some Unix tools on your Windows box that uses NFS
Or mount the file system on the control station – don’t forget to umount
Or you can use server_cifssupport to determine the access that a particular account has to a specific file
The options take a bit to get used to but it works
If you are just using NFS with NATIVE access policy then secmap shouldn’t matter – there is no mapping
Your NFS client sends a UID (which is determined by the client) and the NFS server (Celerra) compares it to the rwx rights for user/group/other
If you are not familiar with Unix access rights I suggest a quick google or a Unix book
My guess is that these files were created from CIFS – for that they get dual ownership / permissions
First the Windows owner and ACLs and the the Unix uid/gid and access rights
The uid/gid are dermined by user mapping – in your case the default building usermapper
The Unix access rights for files created via CIFS are determined by the global umask or the per-share setting.
By default that wont give group or others write access.
I order to fix that you can either change the mapping so that your Windows NFS user matches the user or group the files belong or change the umask to allow all others
Alternatively – if you don’t have that much about security - you can let your Windows NFS client use root as the user and root-export it to that client.
In Unix/NFS root is god and for UID 0 access controls aren’t checked. Just be aware that from this clients NFS mount any files can be changed/deleted no matter what the rights or ACLs say
Rainer