One other thing to be aware of (ran into it today as I was reconfiguring my personal offline cache):
If the share where the data resides does not provide the user with access, even if their personal directory does, then synchronization will fail. In that case, you'd have to have each user access their own share (essentially using the homedir functionality) or make it so that each user has privileges to the share itself (assuming read will be enough).
Glenn
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Christopher Mende Sent: Thursday, August 10, 2006 5:02 PM To: toasters@mathworks.com Subject: RE: CIFS homedir offline file synchronization
Thanks for your response Marty & Glenn,
This KB looks like it should tackle this issue. Windows can't synchronize files into the cache for a share that essentially doesn't exist -- the share is only accessible when authenticated as that particular user. But not sure if it's practical to stamp primary SIDs on the desktops ... the users are relatively mobile.
I'm far from a strong Windows admin (Unix background) so this is a bit of learning for me.
I may suggest to create a top-level share, homedirs$ and reference each user's directory as \filer\homedir$%username% instead of \filer%username% (using the CIFS.HOMEDIR functionality). That way the share always exists ... and Windows can blindly sychronize stuff that doesn't need to be. :-D
C
Christopher Mende Systems Engineer
Infinity Solutions Ltd P O Box 3323, Auckland Ph: +64 9 921 8039, Mob: +64 21 227 7590 Fax: +64 9 309 4142 www.infinitysolutions.co.nz
-----Original Message----- From: Marty Wise [mailto:Marty.Wise@jlab.org] Sent: Thursday, 10 August 2006 11:10 p.m. To: Christopher Mende; toasters@mathworks.com Subject: RE: CIFS homedir offline file synchronization
Chris,
I am not familiar with the error masking behavior you describe, but I
have
done some tinkering with this issue from another perspective.
Apparently, Windows uses a global offline file cache on a system. A synchronization event will trigger a synchronization of files for all users by default. This is made even more annoying by various files which
cannot
be synchronized (MS Access files among others) that generate errors
during
the synchronization attempt. In our specific situation, it is users who
only
occasionally log in to a system (mostly admins and support folks) that
get
synchronized needlessly during sync events triggered by the real user
of
the system. A bit of digging revealed that Windows provides controls that alleviates much of this problem for us.
There are registry entries (that can be set via group policy) that
allow
you to specify a list of "Primary" users of a system for offline files
(other
entries allow you to ignore specific file extensions during synchronization). Offline files uses the list of primary users to
attempt
synchronization of only files for those users. In our case, this
avoids
synchronizing files for our admins, etc. The configuration is
described in
MS KnowledgeBase article ID # 811660. (http://support.microsoft.com/?kbid=811660)
I'm not sure if this is useful in your situation.
Regards,
Marty Wise Computer Center, Windows Systems Team Thomas Jefferson National Accelerator Facility 12000 Jefferson Ave. Newport News, VA, 23606
From: owner-toasters@mathworks.com
[mailto:owner-toasters@mathworks.com]
On Behalf Of Christopher Mende Sent: Thursday, August 10, 2006 12:49 AM To: toasters@mathworks.com Subject: CIFS homedir offline file synchronization
Hi All,
Anyone run into issues with offline file synchronization for homedirs?
Have an issue where user1 logs in and out, and sync works just fine.
User 2 logs in and out & syncs, plus it tries to sync user1 again,
which
fails.
According to M$, if you were using one of their servers, the share permissions on the user share would be set to Full Control, and
Windows
would actually mask the failure.
Seems this isn't happening when using the filer - any ideas short of scrapping the auto-homedir feature? How does one change the share permissions on these auto-gen'd shares which aren't accessible via traditional methods? If that's really the fix.
Christopher Mende
The information contained in this email is privileged and confidential
and
intended for the addressee only. If you are not the intended
recipient,
you are asked to respect that confidentiality and not disclose, copy or
make
use of its contents. If received in error you are asked to destroy this
and contact the sender immediately. Your assistance is appreciated.
The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.