You need to replace drive showing 4321 firmware. See also http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=529888 You are "lucky" - there was only limited number of these drives
... View more
In my opinion, it is a security hole, no matter whether UIDs or names are used. Well ... traditional NFS authentication model is weak, there is nothing new. Use Kerberos if you need something more trustworthy. It can be exploited easily, so why bother about UIDs? Forget about UID. I apologize for causing this confusion. It is not about UID, it is about verifying that user name supplied by client actually exists. It does not add any extra security or am I missing something? In your specific case it prevents client from supplying user name Administrator (or any user name for that matter) and getting some more access than intended. By verifying user name NetApp can restrict access only to authorized users. As long as users on these hosts have no root access to their host, its fairly safe. Nothing precludes user space NFS client implementation ...
... View more
User lookup will happen for all NFS versions, regardless of options if the volume is NTFS security style. There is not any way to get around that, as there needs to be a way to discern the NTFS ACL for the user requesting access. Now I became curious myself To discern NTFS ACL you need to know Windows user name (OK, you need Windows SID, but let's keep it simple); to get Windows user name you need to know Unix user name and with NFSv4 you get user Unix name from client already. So what is technical reason to perform user lookup at this point?
... View more
If we're talking NFSv4 and bypassing the user string, No, we are talking about using user string in NFSv4 but bypassing Unix user lookup on NetApp side.
... View more
But there is, and will not be, a way to bypass UID/GID. It's a security hole. You don't want to allow anyone access to your data without needing a valid user. I think what confuses OP here is that we both speak about UIDs. OP is right in that strictly speaking UID are not needed in described scenario. What really happens here is user validation on server side. NetApp gets client user name in NFSv4 request and it must verify that user with this name actually exists from server point of view. So it must perform Unix user name lookup first. That this lookup returns UID as side effect is irrelevant in this context. This validation likely happens even before NetApp tries to access file (and knows its security style).
... View more
UIDs/GIDs are still required at RPC level, which does not change with NFS v4. It could be that using NFS v4 with Kerberos bypasses this, but I do not have practical experience. IIRC your example explicitly used auth=sys which does need to know numerical IDs. Also NFS v4+ still allows pure numerical IDs as fallback, so storage still must be prepared to resolve them. Also for security style unix Data ONTAP stores numerical IDs internally and again must be able to resolve them. I doubt it has two different code paths. User mapping rules are configured in /etc/usermap.cfg; you mentioned this file yourself. It is possible to do without common backend; it is just that for any practical purposes it becomes unmanageable very fast unless you need to grant access to fixed number of users that change infrequently.
... View more
NetApp must be able to a) map Unix user name to Unix user UID and b) map Unix user name to Windows user name. You said nothing about configuring user mapping, so I assume nothing is configured ☺ In practice that means that NetApp and Unix must use the same user database backend, most likely LDAP. And to ensure that Unix user means the same as Windows user, this LDAP backend usually must be AD. Please see tr3490 for details on multiprotocol access and tr3458 for example of using AD as common backend.
... View more
There are a couple of KB articles - I’ll leave the fun to search for them to whoever is interested ☺. From experience, when you create LUN DOT tries to compute number of cylinders approximately 1/10th of maximum value (64k). This is because number of cylinders is the only parameter that can be safely increased after initial creation (yes, there still exist operating systems that base disk partitioning on CHS values …). That is exactly the reason for proverbial “you can only increase LUN size to 10 fold of original size”. And then computes other values (tracks per cylinder and sectors per track) to fit resulting size.
... View more
For legacy reasons NetApp fakes CHS geometry for a LUN, so full size will always be multiple of cylinder size. Exact geometry depends on os type for the same legacy reasons.
... View more
I was not even thinking about GUI - I never do anything like this with it. Oh, and do you have BMC connection? Then you would have remote access to console and could perform system initialization remotely.
... View more
You still should be able to create new aggregate, may be using -f option if necessary. You can convert aggregate into RAID4 (aggr options raidtype), but I would not do it. It is not needed and RAID_DP without spares provides better protection during data migration than RAID4 + spare.
... View more
If you replace adapter in the same slot - yes, should be straightforward. Check HWU whether your Data ONTAP version supports your adapter. If yes, it will be auto detected and interface names remain the same.
... View more
Yes, snapshots with names containing destination and sysid are SnapMirror snapshots. They are created automatically every time SnapMirror is updated (unless snapshot is specified explicitly). What happens here most likely is - SnapDrive creates "consistent" snapshot on source - SnapMirror is updated created next xxx.n snapshot. This updates transfers also SnapDrive snapshot, which is earlier than SnapMirror snapshot. - when LUN is connected on destination, it is reverted to SnapDrive snapshot - this by definition removes all later snapshots. As I already mentioned, to me most surprising is missing SnapDrive snapshot on source.
... View more
I wonder, where srv01_snap_recent on source is gone? That seems to be the actual problem. But with snapshots shown, you still have at least one common snapshot that should allow resyncing back (or forth).
... View more
Yes for NFS, no for iSCSI, at least today. I have heard rumors that LUN SnapMirror may be supported in 8.3, but until it is released ... Who knows. If you need to migrate today, you need to use host based migration for LUN data.
... View more
For shelf issues, there is a feature called "hot shelf removal" (added in 8.2.1) that can be used in conjunction with aggregate relocation to allow you to power cycle, remove shelves, etc. Are you sure it is aggregate and not volume reallocation? To hot remove shelf it must be empty which means all data must be evacuated and aggregates on this shelf destroyed. Aggregate relocation changes ownership but not physical placement; to evacuate data one would need to move volumes off to another aggregate.
... View more
Any snapshot can be used as common base snapshot when doing resync, including SnapDrive consistent snapshot. Please show snap list from both source and destination.
... View more
In recent Data ONTAP autosupport.to gets only selected notifications. To send all notifications to partner support you need to use autosupport.partner.to.
... View more
Most probably this is due to "sparse files". I.e. When you create 100G file you do not really write anything, so from NetApp side it occupies nothing. First when you start writing to this file it starts consuming space on NetApp.
... View more