2011-05-25 04:05 PM
I have just cut-over all of our users roaming profiles and am now getting an error. I think this is because of OFFLINE CACHING needs to be disabled for these profile types.
Is there a way to do this "after the fact"? As in- I have already created the share, but noticed in "Widows File-Service-best-practice" that this can be disable while creating the share.
I created a NEW share to test, but that option was not there.?? How can this be accomplished or should I just go back to using a "Windows Share"?
right-click on the share does not bring up a "share" tab, so no way to do it graphically?? Perhaps thru CLI??
ONTAP V 7.3.5
Thanks in advance
2011-05-26 06:15 AM
You can also do this on the cli:
cifs shares -change <share_name> -no_caching
You can get an overview of the manpages (manual pages) for the cli commands here:
I really hope you aren't using ONTap 7.3.5 . This release was pulled from availability. Update to 126.96.36.199 (or some P level) if this is the case.
2011-05-26 03:51 PM
Thanks for the help.
Before I commit this......question.
I would then assume that I really shud have a seperate volume for any "roaming profiles" and keep them completly seperated from any other data?
As it is...as in the Windows world, netprofiles were in their respective folder but kept on a "common" share along with everything else that was sharred out.
Would this be a correct assumption? And turning off cache for anything BUT roaming profiles is probably not a good idea??
ps; Ontap 7.3.5...yes. Strange because Netapp set this up in Feburary 2011 and he mentioned nothing about this release being bugy....when did 7.3.5 become moot?
P level downloads don't seem to be available. I have downloaded 188.8.131.52 and will plan the upgrade soon, along with BIOS/BMC firmware update as well.(30801781)
2011-05-26 04:10 PM
You might have some advantages in keep profiles in a separate qtree, but since this is essentially a property of the CIFS protocol and can be set on a share basis, the share could basically point to any directory. It doesn't really have any other effects on the WAFL file system. Things like whether or not you want to qtree snapmirror it or perhaps not take backup of it are probably more deciding factors than a CIFS setting eliminating file caching.
2011-05-31 09:59 AM
I went ahead and disabled the caching for the share that has the roaming profiles. It has not made any difference to my problem. Initially I copied ALL the roaming profile using Robocopy and retain all share permissions etc. So when I look at the folder where all the profiles are a couple of things:
Root Folder: Netprofiles = Read Only checked and greyed out
ALL user profile subfolders = ditto
Logging in to Windows server or XP machines I get the same problem.
Unable to load the administrator profile and also said the disk was full?? This Netapp share has 90GB of free space. How can the disk be full?
Windows Roaming Profiles are bad to begin with, but now I think my only choice is put them back on the windows server.
I hate roaming profiles to begin with, but this is getting ridiculous.
2011-05-31 11:50 AM
"P" levels are available by using the download selection at the very bottom of the software download page. Just select ONTAP and then enter the release number manally, like 184.108.40.206P2
You might want to familiarize yourself with the fixed bugs pages and read the fixed bugs before downloading a "P" release. There is probably no real "safe havens" as far as software version choices.
2011-05-31 12:00 PM
I think the problem needs to be dissected a little here. You started out with the assumption that the caching settings for the CIFS share were the cause of the problem. Perhaps this is not the case at all. Caching settings don't affect filesystem permissions. Basically, these are are just files and they should behave as any other files given the correct configuration of the filer. There should be no specific reason to have to move them to a windows server unless you are using some sort of MS Windows specific functionality like DFS-R for profiles.
You probably need to divide the problem up into smaller pieces and try things step-by-step. It will make solving the problem a little more manageable, at least.
Make a simple CIFS share (after you have created a volume and qtree just for this purpose) and add a single profile with robocopy and make the changes to AD necessary that it will be used. Test that. Enable the "options" necessary to give you more verbose logging about file access events.
I think you either have used some incorrect flags (options) with robocopy, or you have set some sort of strange CIFS share access rights, or you have changed rights somehow in the directory stucture above the profiles that has been propogated downwards into your profiles.
Either way, you don't seem to have a clear enough error from the filer to be able to proceed, so I assume you don't have some of the additional logging enabled or don't know where to look for it.