[Tarny]

Here is another issue with the same error message. There is an Active Directory with a Mac OS X Server correctly bound. When connecting via ssh to (server.pretend.com) the Mac OS X member server (i.e. the member server role is “Connected To”) the “[b]Could not chdir to home directory[/b] error message occurs.”

[code]
ssh [email protected].2.7
Password:
Welcome to Darwin!
Could not chdir to home directory /Network/Servers/server.pretend.com/Users/user: No such file or directory
server:/ user$ printenv
TERM=xterm-color
SHELL=/bin/sh
SSH_CLIENT=192.168.2.9 57217 22
SSH_TTY=/dev/ttyp2
USER=user
MAIL=/var/mail/user
PATH=/bin:/sbin:/usr/bin:/usr/sbin
PWD=/
SHLVL=1
HOME=/Network/Servers/server.pretend.com/Users/user
LOGNAME=user
SSH_CONNECTION=192.168.2.9 57217 192.168.2.7 22
_=/usr/bin/printenv
[/code]

I understand that the HOME environment variable is being set from the NFSHomeDirectory attribute in Open Directory, but I don’t understand how we can modify this so that for ssh connection is it the shorter local path and yet for login window connections with network home folders it is the longer network path.

Should I look at scripting something in say ~/.profile or ~/.bashrc ? But, if I do that, I’ll have to determine local versus remote sessions so that I can use the correct path. It would be annoying to startup terminal.app and have it give me that chdir error message.

Looking forward, I’m thinking that other services on the member server might need modifications like this so that home directorys use local paths rather than network paths. But, at the same time we need to maintain that darn network home directory path for the Login Window connections.

[i]T.[/i]

[Tarny]

Yep, I WAS overlooking something obvious. When using SMB/CIFS protocols, the ONLY type of KDC Mac OS X supports for single sign on is an Active Directory KDC. Doh! I feel silly for forgetting that.

When I tested with Windows XP clients at first there were connection problems. A simple unbinding of the Mac OS X “connected to” server and a carefull removal of the following files:
/etc/krb5.keytab
/Library/Preferences/edu.mit.kerberos
/Library/Preferences/DirectoryService/*

Then rebind into AD. After that I had to leave the customer site, but the customer tested the XP clients and says that SSO to the OS X Server “Connected To” server is working as expected. I’ll be checking up on them on Friday.

The moral of the story is that one should test with the appropriate systems.

😳

T.

[Tarny]

Well, I just visited a customer today and I’m seeing symptoms as described above. There are some things that I didn’t set up myself such as the “Connected To” server and the Active Directory server in our scheme was set up before I arrived. The OpenDirectory Master I did set up.

Same symptoms:
1) Mac OS X Clients allow uses in the AD to login at the login window
a) correctly receive the Kerberos TGT
b) home folders are fine with AFP (automount records are in the OpenDirectory Master, the Connected To server is operating just fine as a Kerberized AFP file server using the AD KDC)
2) From a Mac OS X Client we can “Connect to Server” to one of the AD file servers and it works seamlessly as a SSO environment.
a) I did forget to Set “Microsoft Network Server: Digitally sign communications (always):” to DISABLED at first, but quickly remembered it.
b) The ticket I receive from the AD file server is similar to the [email protected]
3) From a Mac OS X Client we can also “Connect to Server” to the “Connected To” AFP file server to other share points seamlessly.
4) When trying to connect from either a Mac OS X Client or Windows XP client to the “Connected To” SMB file server (same server as the AFP file server) we receive a tickect as in 2b above but the the user isn’t authenticated. We are seeing error messages in the Windows smb log that sort of indicat a bad password. (Sorry I can’t post the log messages from here, I don’t have access to the logs at this minute.)

I feel I’ve overlooked something basic.

T.

[Tarny]

I had a customer with a similar problem. One a 10.4.4 server the sharing tab was grayed out and in ServerAdmin the Settings window was missing, so we couldn’t get access to the General, Network, Date & Time, Certificates, or Access tabs. Here’s the solution we used, but this may be a quick sledge hammer method. I’d be interested to know if anyone comes up with a slicker method for this type if issue.

SOLUTION:
We backed up the server’s system volume completely (made an image to an external FW drive with asr.) Then, we applied the 10.4.4 server Combo update, even though the server had been recently updated to 10.4.4. At that point, we restarted, tested and the missing windows in Workgroup Manager and Server Admin came back.

Hope that this helps.

Tarny

[Tarny]

I have 2 customers that are experiencing high utilization of the CPU by the second AppleFileServer process. Both customers have Mac OS X Server 10.4.4. One customer is updating to 10.4.5 tomorrow.

I see that there hasn’t been a lot of traffic on this thread since October of last year. Has the problem “gone away” for everyone? Or is there a solution?

Using top I can identify that the AFS process is taking about 10-20% of the CPU when there are very few connections and it is just sort of idling. Once the actual work starts, it will average over 95% utilization.

Here’s some more information about the servers and environments. Both customers have xServes. Both have Open Directory Masters. One has the file services on the ODM, the other has an ODM plus replicas and two file servers connected to the directory services. One customer only uses built in hard drives, the other has an xServe RAID connected to the two file servers. In both instances the networking infrastructure seems solid, gigabit ethernet, switches. Note, the CPU utilization and apparent slow down of service to the users occurs even if the users are connecting via wireless connections. Both customers have extensive wireless, but the wired connections have slow service too and the CPU still seems to be working excessively hard.

Lot’s of good suggestions in this thread and we are working our way through them, but I note that nothing appears to be a “silver bullet.”

Tarny

[Tarny]

I tried to get SSO working in an AD integrated network. There were 4 Windows servers, 2 Win2K servers that are both domain controllers (and both are KDCs), there is 1 xServe with an Xserve RAID. The other 2 Windows servers are Windows 2003, but are supposedly not involved directly in anything yet.

The full story is too long to recount here, but the short version is that we got the AD integration part working, so that AD logins on Mac OS X clients worked but the AFP home directories on the Mac OS X Server wouldn’t mount.

We finally resorted to calling Apple support. After having the configuration double checked by Apple (it was in line with the popular articles here on AFP548 and with Michael Bartosh’s articles) the Apple tech suggested that there was a known problem with SSO in Samba 3.0.5. However, he wasn’t SURE and was going to consult with Apple Engineering. Unfortunatly, my customer didn’t get any call back within a couple of days, so he gave up on the subject. Apple tech never called back since the incident was closed.

With the customer, we are working around the problem simply by setting up a non-integrated OD server for now.

I’m experimenting to see if there really is a problem with Samba 3.0.5 that later versions would fix.

Tarny

[Author]

Posts