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.
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.
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.