Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Home directory and personal website trouble after 10.6.7 Server

Xserve recently upgraded to 10.6.7 Server and it seems to have broken two features:


When doing Connect to Server as an LDAP user their home folder is no longer available as a mountable volume. The share that holds all user home folders IS available so that's not the end of the world.


However this also broke the personal web sites, so going to:


http://<serveraddress>/~shortname now just gives a 403 error


and I get these errors in the error_log (under WebServer in Console)

[Tue Aug 24 11:38:48 2010] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Mon Apr 25 09:11:22 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed

[Mon Apr 25 12:39:39 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed


The sharepoint is on an old XServe RAID unit connected directly to server via FibreChannel, but that hasn't changed in a long time...only recent change was running all Software Updates which included moving up to 10.6.7 Server.


Any ideas what I'm missing or where to start looking to resolve this?


Thanks!

Xserve, Mac OS X (10.6.7)

Posted on Apr 25, 2011 10:08 AM

Reply
7 replies

Apr 26, 2011 2:39 PM in response to Dave Walsh

You probably need to reset the webserver's default location.

The log file there says that apache is looking in /Library/WebServer/Documents


You say that the sharepoint is an Xserve Raid device.


I presume that the server's main drive or / isn't in fact on the xserve raid, correct?


That said, in Server Admin go to the Web Service.

Click "Sites"

Click on the site in question from the list of hostnames.

About half way down, there's a field there called "Web Folder"

Make sure that the correct root level of the website is entered.


Within that folder, if there are any links to users folders, it's safe to delete them. OS X Server knows that when you type os.x.server.com/~username it'll look to the users Sites folder. It doesn't require a link in the web folder. Nor does it require a redirect in the server admin program.

Apr 26, 2011 3:03 PM in response to Dave Walsh

When doing Connect to Server as an LDAP user their home folder is no longer available as a mountable volume. The share that holds all user home folders IS available so that's not the end of the world.


There are so many ways of configuring home directories that this can't be answered without more information.


For example, are you using automount to mount the user's home directory when they log in?

or do the clients mount a static mount and their Open Directory record just includes a link to the (mounted) home directory?


However this also broke the personal web sites, so going to:


http://<serveraddress>/~shortname now just gives a 403 error

The answer to this probably lies in the above solution, too. In general you need mod_userdir enabled in Apache to get ~username links working, but even if that is enabled it stil might not work if the home directories aren't where they should be (or where Apache expects them to be).

Apr 27, 2011 4:28 AM in response to Camelot

Camelot wrote:


When doing Connect to Server as an LDAP user their home folder is no longer available as a mountable volume. The share that holds all user home folders IS available so that's not the end of the world.


There are so many ways of configuring home directories that this can't be answered without more information.


For example, are you using automount to mount the user's home directory when they log in?

or do the clients mount a static mount and their Open Directory record just includes a link to the (mounted) home directory?

We are using automounts to get users their home folders. And when logging in at a terminal with an LDAP account you do get into your account as expected. It's only Go -> Connect to Server that won't give the home folder as a sharepoint and the web service for user sites that we agree are most likely tied together.


I have both userdir_module and apple_userdir_module enabled at the moment, although when I tried just one or the other I was getting an Object does not exist rather than the permission error.


I think the key to solving this is in the console log entries httpd -> error_log:


errors before posting:

[Tue Aug 24 11:38:48 2010] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Mon Apr 25 09:11:22 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed

[Mon Apr 25 12:39:39 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed

[Mon Apr 25 14:40:17 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed

[Wed Apr 27 06:57:03 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed

[Wed Apr 27 06:57:17 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed


with userdir_module disabled and apple_userdir_module enabled:

[Wed Apr 27 06:57:32 2011] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Wed Apr 27 06:57:34 2011] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Wed Apr 27 06:57:35 2011] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Wed Apr 27 06:57:49 2011] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd

[Wed Apr 27 06:57:50 2011] [error] [client 10.2.104.16] File does not exist: /Library/WebServer/Documents/~walshd


with userdir_module enabled and apple_userdir_module disabled:

[Wed Apr 27 06:58:02 2011] [error] [client 10.2.104.16] File does not exist: /Network/Servers/staff.lsrhs.net/Volumes/Staff/Home/walshd

[Wed Apr 27 06:58:03 2011] [error] [client 10.2.104.16] File does not exist: /Network/Servers/staff.lsrhs.net/Volumes/Staff/Home/walshd

[Wed Apr 27 06:58:04 2011] [error] [client 10.2.104.16] File does not exist: /Network/Servers/staff.lsrhs.net/Volumes/Staff/Home/walshd


with both enabled again:

[Wed Apr 27 06:58:22 2011] [error] [client 10.2.104.16] (62)Too many levels of symbolic links: access to /~walshd failed


The strangest thing about this issue is that it happened after I applied a bunch of updates last week:


2010-04-22 12:52:17 -0400: Installed "Remote Desktop Client Update" (3.3.2)

2010-04-22 12:52:23 -0400: Installed "AirPort Base Station Update 2010-001" (5.5.1)

2010-04-22 12:52:39 -0400: Installed "QuickTime" (7.6.6)

2010-04-22 12:52:41 -0400: Installed "Xserve EFI Firmware Update" (1.1)

2010-04-22 12:52:44 -0400: Installed "iLife Support" (9.0.4)

2010-04-22 12:52:59 -0400: Installed "Java for Mac OS X 10.5 Update 5" (1.0)

2010-04-22 12:53:21 -0400: Installed "iTunes" (9.1)

2010-04-22 12:54:31 -0400: Installed "Security Update 2010-003" (1.0)

2010-04-22 12:55:16 -0400: Installed "Safari" (4.0.5)

2010-04-22 13:15:22 -0400: Installed "Java for Mac OS X 10.5 Update 6" (1.0)


Could any of these have broken the home directories sharepoints or is this just a huge coincidence?

Apr 14, 2012 12:18 PM in response to Dave Walsh

I know it’s been a few months, but I was having the same exact problem as the OP: after performing some software updates on our server, users’ home folders no longer showed as an available volume to mount and their personal Web sites were broken. Apache was giving the same error, also: “Too many levels of symbolic links.”

I didn’t want to completely rebuild the server, so after closely inspecting every log I could think of and hours of research and tinkering, I was finally able to find the root of the problem: the server’s hostname had been changed. The server hostname had been reset to servername.local causing loads of confusion for the server’s services (like Open Directory and the Web server).

To make things more confusing, the computer name listed in System Preferences > Sharing is not really the hostname of the computer; this value should really be called the Bonjour name. To set the correct hostname of the server, perform the following at the Terminal and then reboot:

scutil --set HostName correct.server.host.name

Where correct.server.host.name is, obviously, the correct hostname of the server. To ensure that the hostname has been set properly, perform the following:

scutil --get HostName

I still need to figure out why this all happened, and which software update did the damage, but everything is working again.

Home directory and personal website trouble after 10.6.7 Server

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.