Failing automounts on AFP server

[luke]

On a clean install of Leopard server, I created 5 share points and shared them via AFP. I’m able to connect to them manually from other machines. I configured automounts for them, and then rebooted the server. They show up in /Network as expected, but are not accessible. When I access it in the Finder, it simply redisplays /Network. If I access it in the terminal, I get:
[code]ls: : Too many levels of symbolic links[/code]

In system.log, I see the following:
[code]Jan 14 14:28:21 vodka /System/Library/CoreServices/coreservicesd[95]: \
SFLSharePointsEntry::CreateDSRecord: dsCreateRecordAndOpen(Applications) returned -14135
Jan 14 14:28:21 vodka /System/Library/CoreServices/coreservicesd[95]: \
SFLSharePointsEntry::CreateDSRecord: dsCreateRecordAndOpen(Groups) returned -14135
Jan 14 14:28:21 vodka /System/Library/CoreServices/coreservicesd[95]: \
SFLSharePointsEntry::CreateDSRecord: dsCreateRecordAndOpen(Library) returned -14135
Jan 14 14:28:21 vodka /System/Library/CoreServices/coreservicesd[95]: \
SFLSharePointsEntry::CreateDSRecord: dsCreateRecordAndOpen(Users1) returned -14135[/code]

According to the [url=http://developer.apple.com/documentation/Networking/Reference/DirectoryServiceFramework/DirServices/index.html] developer documentation[/url], this error code corresponds to:
[code]eDSRecordAlreadyExists = -14135[/code]

I’ve removed the automounts and recreated them, and I’ve cleaned out the /LDAPv3/127.0.0.1/Mounts/. There is nothing in /LDAPv3/127.0.0.1/Automounts/ or /LDAPv3/127.0.0.1/AutomountMap/.

Any suggestions?

[luke]

I just reformatted and started from scratch, and got the very same behavior.

My steps were:

1. Install advanced server

2. Enable reverse and forward DNS

3. Enable AFP

4. Enable automount on the Public share point which was already created for me (mounted at /Network/Public)

5. Try to access that share point from this server.

I guess this is the correct behavior?

[luke]

I called Apple’s corporate support today about this. They were able to recreate it in their lab in a few minutes and were surprised that this used to work in Tiger. They’ve opened a bug ticket to look into it and may fix it or else declare it as expected behavior.

So at least for now, a Leopard server will not be able to see its own shares automounted in /Network

[ChrisOwens]

Additional data point:

On a Leopard Workstation (not server) — I did the following:

1 mkdir /foo

2 use the GUI (“Sharing” control panel item) to share /foo with read/write by everyone

3 reboot the machine.

The log shows the -14135 error identical to what is in your log quoted above

Other hosts can mount and use the sharepoint

.DS_Store, Temporary Items, and Network Trash Folder do not show up in the directory

I also noticed that when I accessed /foo from another machine via AFP, and I authenticated as user bar, user bar’s home directory was available as a share, even though it had never been set up as one. In other words, user home directories seem to be shared auto-magically.

[ChrisOwens]

[QUOTE][u]Quote by: macshome[/u][p]I’m a bit confused here. Although it probably shouldn’t error out on you, why would you want to loopback via the network to a directory on the server itself? [/p][/QUOTE]

If I want every machine in my domain to mount the [b]bar[/b] sharepoint on host [b]foo[/b], i’d create a mount record that mounts [b]foo:/bar[/b] in [b]/Network/Servers/foo[/b].

But what happens on [b]foo[/b] itself? It’s part of the domain, too, so it sees the mount request also. Automount is smart about this — it recognizes that the mount request refers to the local host, and instead of doing a mount, it just creates a symlink from /Network/Servers/foo to /

That means that you can always refer to /Network/Servers/foo/bar, and it will work correctly whether you are running on foo or whether you are running on any other machine in the domain.

[ChrisOwens]

[QUOTE][u]Quote by: macshome[/u][p][QUOTE][u]Quote by: ChrisOwens[/u][p][i]Additional data point:

I also noticed that when I accessed /foo from another machine via AFP, and I authenticated as user bar, user bar’s home directory was available as a share, even though it had never been set up as one. In other words, user home directories seem to be shared auto-magically.[/i]

[/p][/QUOTE]

Auto-sharing of the home folders has been the default for some time now. 10.4 at least, but I think even 10.3 did it.[/p][/QUOTE]

Is that something you can turn off?

[krunk]

[QUOTE][u]Quote by: macshome[/u][p]I’m a bit confused here. Although it probably shouldn’t error out on you, why would you want to loopback via the network to a directory on the server itself? [/p][/QUOTE]

Was searching for a fix for this problem and ran across the thread. Thought I’d give a specific example, bump the thread, maybe someone has found a solution.

Some applications/programs depend on it’s install prefix to execute correctly. Thus if you’d like to install the application for use on all clients, the –prefix path should be the same on the server as on the clients.

The current bug can usually be worked around by setting the –prefix client’s will see and using the DESTDIR variable when doing a make install. Another way is to compile/install on a client directly to the afp share. However, this is not an option with some applications. One such example is matlab.

[Author]

Posts