Recent samba update to 3.5.6 creates problems on Windows 7 with roaming profiles. Roaming profiles on Vista machines still work correctly on 3.5.6 but Windows XP machines seem to also have problems, specifically with desktop.ini files. When running samba 3.5.6 I can log in to a windows 7 box and the roaming profile loads correctly. However, when I try to log off, the roaming profile fails to copy to the server and error messages appear in the event log: --------------------- Windows cannot copy file C:\Users\dijuremo\Music\desktop.ini to location \\p3ha$NOCSC$\Users\dijuremo\.winprofile.V2\Music\desktop.ini. This error may be caused by network problems or insufficient security rights. DETAIL - The system cannot find the file specified. --------------------- While being logged in, if I try to change the location of the Documents folder manually, e.g. Go to C:\Users\dijuremo then right click on Documents, select properties, then the Location tab and move the folder to the samba server, then when I hit apply, the files cannot be moved and the process errors out stating there was an issue copying the files. I went up from samba 3.3.5 to 3.5.6 since I had problems with Windows 7 machines not being able to talk to 3.3.5, but after I found the problem with profiles on 3.5.6, I downgraded to 3.4.9 and everything works just fine with 3.4.9. Will upload a full copy of the windows event log showing the errors. I am also not sure, why is it that the server name has the additional $NOCSC$ prefix in the entries, but google did not turn out many answers. If anybody could explain what \\servername$NOCSC$ means, I would appreciate it.
Created attachment 6056 [details] Windows 7 event log on affected machine
I have once again noticed this situation on a RHEL 5.6 machine running RHEL packaged samba: [root@phys-file01 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.6 (Tikanga) [root@phys-file01 ~]# rpm -qa | grep samba samba3x-3.5.4-0.70.el5_6.1 samba3x-winbind-3.5.4-0.70.el5_6.1 samba3x-common-3.5.4-0.70.el5_6.1 A workaround for the problem is to enable an option in group policy to skip the permissions check for the user's roaming profile. Policies |->Administrative Templates |->System/User Profiles |->Do not check for user ownership of Roaming Profile Folders Set the option to enable. In the windows logs, without that option enabled, event viewer shows: Windows cannot locate the server copy of your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you log off. This error may be caused by network problems or insufficient security rights. DETAIL - Logon failure: unknown user name or bad password. There are also folder redirection errors that seem related to permission issues which disappear after the GPO option to omit checking for permissions have been set: Failed to apply policy and redirect folder "Downloads" to "\\phys-file.physics.gatech.edu\mdingler3\Documents\Downloads". Redirection options=0x1001. The following error occurred: "Can not create folder "\\phys-file.physics.gatech.edu\mdingler3\Documents\Downloads"". Error details: "This security ID may not be assigned as the owner of this object. ".
Have you set "profile acls = yes" on that profile share ?
(In reply to comment #3) > Have you set "profile acls = yes" on that profile share ? I have not tried that option yet, however the security implications seem bad. I do not have a separate profiles folder share in samba. Each user has their profile in their own home directory which is shared via the [Homes] share. We have multi-user machines, so having the group owner be BUILTIN\\Users is not a good idea. I have seen several posts where it is not recommended to use "profile acls = yes" on any other where users will store files which are not part of the profile. Seems to cause more issues. What is your take on this? Would you set "profile acls = yes" in the [Homes] share? Also, the problem did not exist with 3.4.x, but seems to exist by simply updating to a 3.5.6 version I compiled myself using the makerpm.sh script from the samba distribution, and also in the 3.5.4 samba3x rpm packages directly from RHEL on 5.6. If all that has changed is the version of samba in the server, does it really make sense to need the "profile acls = yes" option on 3.5.x but not on 3.4.x?. Also note that this seem to have affected only XP and Win 7 machines, but not Vista machines in my initial bug report. Thanks for your suggestion and look forward to a reply.
I was wondering what the $NOCSC$ prefix was myself when I saw it once, so I did a bit of looking around.. knowing the local csc directory was for offline files, i figured it had to be something related to offline files and file sharing servers.. turns out that in order to bypass local CSC cache (Offline Files) when browsing network shares, you append the server name with $NOCSC$: \\servername$NOCSC$\share\folder