Hello Alan,
Hi Ryan,
Just curious - if you have an NFS licence on your filer, why are you even bothering to mount a CIFS share rather than an NFS v3 export?
We ran Mixed Security mode on OnTap 6.5, but upon NetApp's recommendation we moved to NTFS security mode. With NTFS security mode I am unable to map to NFS exports (permission denied error). NetApp has also informed us that in NTFS, or Mixed Mode security, NFS does not maintain a complete copy of filesystem rights.
We are archiving these filers with RSYNC, and it is necessary that we preserve the filesystem rights.
It just seems you are putting yourself through unnecessary trouble. With Secureshare user mapping even SACL's for auditing will still work fine, i.e. NFS reads and writes will still be logged as if they were CIFS accesses.
I agree. I would much rather use NFS. I am not familiar with SecureShare. Is this a way to view the NetApp windows users as Unix UID/GID users? If so, this seems the optimal approach. Of course with NTFS security mode I still cannot mount to NFS exports. Do you know of a way to do this, or would I have to convert to Mixed Mode?
If your Linux box is a server running an application with data stored on the filer, an NFS hard mount (with intr) is much more efficient than a CIFS share - so much so that a few years back I was using the Hummingbird NFS client on Windows 2000 IIS servers rather than use CIFS to support a web farm.
If you set up a dedicated gigabit segment (multi-home both the filer and the app servers) with jumbo frames (large MTU's), you can get as much as 60MB/sec over NFS. That's with 9K MTU's so an 8K NFS transfer is one ethernet packet. Best I have seen on CIFS even with jumbo is 35MB/sec.
(that's MegaBytes, not Megabits).
That is a huge difference. NFS seems a much more elegant solution. I am still confused why I can't use CIFS or SMBFS though against the filer, when they work fine against Windows Domain shares (from Windows Server 2003).
Thanks for your help, and I would be interested in any more information you have on this topic.
Regards, Ryan
regards,
Alan McLachlan Technical Services Manager ComputerCORP ACT
Tel: (02) 6242 3305 Mobile: 0428 655644 Fax: (02) 6255 6333 E-mail: Alan.McLachlan@computercorp.com.au Web: www.computercorp.com.au
LEGAL INFORMATION: This e-mail may contain information which is confidential to ComputerCORP. If you have received this e-mail by mistake, please advise us by return e-mail and delete it and any attachments from your system. You may not disclose, copy or rely on any part of this e-mail
-----Original Message----- From: Ryan Kather [mailto:rkather@missionpenguin.com] Sent: Tuesday, 2 August 2005 10:09 PM To: toasters@mathworks.com Subject: OnTap 7 and Samba
Greetings,
I am having some difficulties accessing our filers with OnTap 7 via Linux. Perhaps someone in this list could point me in the right direction.
The version of Linux is Open Enterprise Server (minimal install) which makes it functionally equivalent to SuSE Linux Enterprise Server 9 SP1. It is running Kernel 2.6.5-155-smp and Samba 3.0.14a (originally 3.0.9 but updated when issues surfaced).
The filers I have tried accessing consist of FAS270s and a R200. They are using FlexVols and OnTap 7. Data shares are available via CIFS and NFS and are configured with NTFS Security Mode. The filers are members of an Active Directory Domain (Windows Server 2003 PDC).
I have a number of odd issues that have surfaced.
Issue 1;
smbmount returns permission denied and odd path presentation.
The Linux box is a member of the active directory domain. I can use wbinfo to list domain users and groups, as well as getent passwd and group. I am able to authenticate via kerberos, and can use smbmount against Windows server shares fine.
However, when I attempt to mount a share on a NetApp filer using mount -t smbfs -o username=someuser,workgroup=THEDOMAIN //NETAPP/SHARE /mnt/SHARE the operation appears to complete successfully. If I enter mount I can see the /mnt/SHARE as active. If I travese into the /mnt/SHARE folder and type ls I get a permission denied error. Syslog shows kernel: smb_lookup: find /// failed, error=-13. After some digging it appears that error=-13 is an EACCESS authentication issue. So I assumed I did not have permissions.
If I type ls -alFG from the /mnt folder in Linux there is no /mnt/SHARE directory. If I type ls there is one, and if I unmount /mnt/SHARE then type ls -alFG the directory is there.
In further troubleshooting I can browse the share from Windows, and from the same Linux workstation smbclient //NETAPP/SHARE -U someuser -W THEDOMAIN allows me to browse succesfully.
Issue 2;
/bin/ls: reading directory .: Cannot allocate memory
If I mount the same share via cifs (mount -t cifs -o user=someuser,domain=THEDOMAIN //NETAPP/SHARE /mnt/SHARE) the operation completes with no error. If I cd into /mnt/SHARE then type ls I get the error above (/bin/ls: reading directory .: Cannot allocate memory). If I continue to type ls it will eventually display the directory. If I cd into a subfolder the error returns.
Both of these operations work fine against a Windows 2003 Server share. Does anyone have any ideas? The messages file on the filer itself does not provide any significant error messages.
Thank you very much for any information anyone can provide.
Linux Config Files;
smb.conf--
[global] workgroup = THEDOMAIN realm = THEDOMAIN.COM idmap uid = 10000-20000 idmap gid = 10000-20000 security = ADS netbios name = LINUXBOX password server = PDC.THEDOMAIN.COM encrypt passwords = yes log level = 5 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 wins server = 10.0.0.1 10.0.0.2 name resolve order = wins lmhosts hosts bcast winbind enum users = yes winbind enum groups = yes winbind use default domain = yes
krb5.conf--
[libdefaults] default_realm = THEDOMAIN.COM
[realms] THEDOMAIN.COM = { kdc = pdc.thedomain.com }
[domain_realm] .thedomain.com = THEDOMAIN.COM
[logging] default = SYSLOG:NOTICE:DAEMON kdc = FILE:/var/log/kdc.log kadmind = FILE:/var/log/kadmind.log
[appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 debug = false }