Network and Storage Protocols
Network and Storage Protocols
Hi,
I need to enable both NFS and CIFS access to the same volume
Should I add this volume to CIFS and NFS list separately or there is some other way to work in such mode ?
Thanks
Solved! See The Solution
he's telling me I can't have a single file share with permissions for both CIFS and NFS set to it at the same time.Is this true?
Yes, that's true. A file on NetApp always has single set of permissions - either CIFS or NFS. The way to share files on NetApp between CIFS and NFS is to map between NFS and CIFS users. Or to map all NFS users to a single CIFS user and give this user (read) permissions.
Please read TR-3490 which decribes in details multiprotocol access issues.
What do I need to request my admin to do, that will allow the CIFS permission to stay as they are but addtionally let the BOBJ application which is hosted on a Unix/AIX server to dump some report files to that same share?
I assume BOBJ applications run as dedicated user. So you can map this user to specific CIFS (Windows) user and give this Windows user specific permissions to this share. If this is one off task, you could add BOBJ UNIX user to /etc/passwd on filer.
Yes, you should configure NFS and CIFS exports separately.
Hi aborzenkov,
My NetApp Admin is telling me there is a security and permissions issue with trying to give one share NFS and CIFS permissions, using the mixed mode.
I guess there is some kind of issue where one permission get set over the other depending on if a Windows user accesses a file or a Unix user does.
Maybe that doesn't make sense, but he's telling me I can't have a single file share with permissions for both CIFS and NFS set to it at the same time.
Is this true?
I need to have the share that he created for me accessed by a Windows Server and Windows PCs but as well I need a Unix server to be able to copy files to the share via some scripts as well.
Is this possible, my NetApp admin is saying its not.
It seems silly since my little $500 ReadyNAS box at home can have both.
Thanks,
Chris
The problem with CIFS / NFS is that Windows has a richer ACL per file than Unix. So if you try to access a Unix-security volume with a CIFS share, the security permissions will be limited. However, if you use mixed mode, or even create a NTFS security volume, you can still access it from Unix (if it is exported as well as a cifs share) and keep the richer security settings.
Thanks for that bit of information Riley.
So since I'm not a NetApp expert nor a storage person, I have to keep asking questions, because you went a little bit over my head there. So please bear with me.
Right now I have been given a share with CIFS permissions to read/write, this allows my PC users to copy some files out to this NetApp shared area.
Now there is a requirement to allow our BOBJ application, which is hosted on Unix/AIX , permissions to genereate some reports and dump them out to that same shared location.
What do I need to request my admin to do, that will allow the CIFS permission to stay as they are but addtionally let the BOBJ application which is hosted on a Unix/AIX server to dump some report files to that same share?
It might have to be a script running on that Unix/AIX server, either way the files will be coming from Unix/AIX and need to land on that CIFS share.
Is that doable? Is so how?
he's telling me I can't have a single file share with permissions for both CIFS and NFS set to it at the same time.Is this true?
Yes, that's true. A file on NetApp always has single set of permissions - either CIFS or NFS. The way to share files on NetApp between CIFS and NFS is to map between NFS and CIFS users. Or to map all NFS users to a single CIFS user and give this user (read) permissions.
Please read TR-3490 which decribes in details multiprotocol access issues.
What do I need to request my admin to do, that will allow the CIFS permission to stay as they are but addtionally let the BOBJ application which is hosted on a Unix/AIX server to dump some report files to that same share?
I assume BOBJ applications run as dedicated user. So you can map this user to specific CIFS (Windows) user and give this Windows user specific permissions to this share. If this is one off task, you could add BOBJ UNIX user to /etc/passwd on filer.
Why is it my simple little $500 investment called a Netgear ReadyNAS NV+ will let me have a share that has CIFS, AFP, NFS, UFS and others all on one share? No issues. Baffles me that the NetApp can't. Maybe I need a better understanding?
At first use, it can be confusing from what other vendors do with multiprotocol (for me too when I first saw it). The key thing is to never use mixed mode (unless a rare edge case which I won't list why/when we have done it in this thread). Choose ntfs or unix then you have a security style set. If ntfs permissions then windows works natively and unix maps a uid to sid (vice versa if unix permissions). Aborzenkov referenced the TR that covers this in detail.
Once you get the setup working it is seamless... with very little to setup. If the usernames are the same between windows and unix, then no mapping entries are needed (you do need name resolution though). When configuring multiprotocol, the wafl credential cache (wcc command) is your friend and is very useful to see how mapping is working... wcc -s sid or wcc -u uid for example to see what the user will map to windows to unix or unix to windows.
Thank you, sorry to ask another dumb question but where do I got to search for TR-3490, and what is a TR? I know its a document, but what does TR mean?
Technical Report... the now site or field portal (field portal if a netapp partner)..
All TRs are here http://www.netapp.com/us/library/technical-reports.html
Dang, is the NOW site for public? My NetApps admins probably have the portal, but I don't. If NOW site is public I can go there.
The tech report link above should be public... and you can create as many now accounts as you need for your company with a valid serial #. You don't need a now account for the link above, but I would get one so you can find other internal links, burts, etc.