[dayglojesus]

[QUOTE][u]Quote by: Stephen+Buckley[/u][p]Does anyone here have any bright ideas regarding what to try next? or what might be a useful thing to look for in my test servers /private/var/log/secure.log on the test server or elsewhere to try and determine why this is failing?
[/p][/QUOTE]

I have seen SST fail for the following reasons:

+++++++++++++++++++++++++++++

1. Insecure or inadequate permissions along the path to the user’s public or private key

At the server level, the entire path to the user’s public key needs to be root accessible, but not so insecure as to prevent SSH from working; SSH demands that private/public keys be “secure” (ie. only accessible to the user) before they can be leveraged. On the client side, the user’s private key and the directory in which it resides must be secure as well.

For example, at the server…

/Network/Servers/your.server.com/Users/your_user/Library/FileSync/FileSyncAgent_key_dir

Along this path the user’s Library/FileSync folder, and sub-folders need to be 0700, the public key should be 0644, and the private key 0600. Ownership along this tree should be solely the user’s.

At the client’s computer along the same relative path, the exact same permissions and ownership should be used. I am not sure why they would be created any differently, but if they are, it might have something to do with your sharing setup.

NOTE: In one case (way back on Mac OS X Server 10.6.0), I found that setting a user’s home dir (NHD, server-side) perms to 0700 fixed the problem. Just that directory though. You could try that I suppose.

2. A bad key pair resulting from a previous FileSyncAgent

Ensure that the key pair on the NHD and PHD are identical by comparing checksums or using diff. If they’re different, you may have found the problem.

3. A stale DirectoryServices cache on the server

Long shot: Try flushing the group membership cache and the like.

4. The client cannot connect to port 2336

Is there a firewall?

+++++++++++++++++++++++++++++

If you can’t get SST to work at all, and you have gone over all the above, I would start looking at your sharing setup very closely. If you are using a combination of posix and ACLs to control access, things can get complicated. Start with a simple perms model, open but secure.

It might also be worthwhile shutting off SST, destroying the FileSyncAgents’s self-generated rsa/dsa keys (/Library/FileSync), firing it back up, and begin your testing again. The keys will be regenerated when SST is re-activated.

That’s a about all I can think of…

HTH

[dayglojesus]

I just wanted to follow-up (close) this thread by saying that the creation of a symlink at the root of the share provides what I consider to be an adequate workaround — and the only one available at present.

The crux of the problem lies in the Active Directory user’s synthesized NFSHomeDirectory value.

When an Active Directory user’s profile path is set using a UNC path of…

\\server.foo.org\share\user

But the actual absolute path to the share in the server’s context is…

/Network/Servers/server.foo.org/Volumes/share

The AD plugin on the user’s workstation will synthesize the remaining home directory related attributes from this one string. For example…

HomeDirectory: afp://server.foo.org/shareuser
SMBHome: \\server.foo.org\share\user
NFSHomeDirectory: /Network/Servers/server.foo.org/share/user

However, if this synthetic value does not reflect the true absolute path in the server’s context, it would be unfair to call this a bug, as the derivation of said value could only ever be considered a “best effort”. Obviously, without being able to specify an NFSHomeDirectory value in an AD account without some form of schema mod, an alternative must be found.

Best practices suggests that this might be implemented by using static/variable mappings, but this feature is not available in the AD plugin (see Phil Rinehart’s article here http://www.mactech.com/articles/mactech/Vol.23/23.10/2310MacEnterprise-Strangersinaforeignland/index.html) as it is in the Apple LDAP plugin.

In this case however, knowing that is it simply the SSHD process for Server Side Tracking that requires the user’s NFSHomeDirectory value, creating a symlink at the root of the system disk should provide an adequate solution.

HTH somebody out there…

[dayglojesus]

[QUOTE][u]Quote by: macshome[/u][p]I would file a bug on that with Apple![/p][/QUOTE]

Thanks for the reply.

Is it really a bug, or just the AD plugin coming up shorthanded? Maybe you can tell me?

If I specify the AD user’s homeDirectory attribute like, \\my.server.com\ShareName\username, that’s all the information the plugin has in order to devise the absolute path to the user’s home directory in the server’s own context. So, even if the absolute path to that share from the server’s context is…

/Volumes/SomeDisk/ShareName

The AD plugin is not going to know this, but will try and devise an NFSHomeDirectory attribute from the UNC path and wind up with something like…

/Network/Servers/my.server.com/ShareName/username

The Server Side File tracking is leveraging the user’s HFSHomeDirectory attribute to determine the path to the FileSyncAgent public key, and this fails because that path is not accessible from the server’s context.

Should the server be able to access its own network shares in /Network/Servers?

If so, then I guess this is a BUG!

[dayglojesus]

Well, after posting this I got to thinking about mining the Apple Software Update log for this info. I had not considered it
before but his could certainly be used as a reference for a script or a simple list as you suggest.

Thanks.

[Author]

Posts