A permission problem of network user home folders

Users do need to have write permission for their own home directory.

Is either of these users logging in locally on the server? If so, see below.

OS X Server: Don't log in to the server with a network user's account

Takuo,

Did you ever resolve this issue? I'm having a similar problem. Linc's comment (about not logging into the server with a network user) doesn't apply -- I'm not logged on with that user, and I have rebooted the server since any possible logins.

Essentially, I have a home network where I've setup OpenDirectory on a Mac Mini Server. I'm authenticating via LDAP properly between my iMac client and my Mac Mini Server. For example, using 'id' at the command prompt, I can properly retrieve all network information, and can use 'ldapsearch' to query user IDs from the server. Perhaps most importantly, I've got pGina setup on a Windows XP machine, and I can authenticate via LDAP against the Server as well -- so I'm pretty sure that I've got the LDAP & DNS parameters all properly configured.

But what I can't seem to figure out is why my SMB shares are failing. Whenever a network user's home directory attempts to get mounted on the iMac client, the home directory authentication fails. For example,

vimac:~ kris$ su - kmv

Password:

su: no directory

On the server-side, I'm seeing:

2014-03-26 8:58:24.256 PM digest-service[43828]: label: default

2014-03-26 8:58:24.256 PM digest-service[43828]: dbname: od:/Local/Default

2014-03-26 8:58:24.256 PM digest-service[43828]: mkey_file: /var/db/krb5kdc/m-key

2014-03-26 8:58:24.256 PM digest-service[43828]: acl_file: /var/db/krb5kdc/kadmind.acl

2014-03-26 8:58:24.257 PM digest-service[43828]: digest-request: uid=0

2014-03-26 8:58:24.259 PM digest-service[43828]: digest-request: netr probe 0

2014-03-26 8:58:24.260 PM digest-service[43828]: digest-request: init request

2014-03-26 8:58:24.327 PM digest-service[43828]: digest-request: init return domain: VSERVER.LOCAL server: VSERVER indomain was: <NULL>

2014-03-26 8:58:24.330 PM digest-service[43828]: digest-request: uid=0

2014-03-26 8:58:24.330 PM digest-service[43828]: digest-request: init request

2014-03-26 8:58:24.534 PM digest-service[43828]: digest-request: init return domain: VSERVER.LOCAL server: VSERVER indomain was: <NULL>

If I use 'smb://' (with a username & password), I also get denied, and the same error about the "NULL" indomain appears in the log.

Is this similar to what you saw? I've been scouring the web for info about digest-request, but am fairly new to OS X, so my progress has been slow...

Kris

Update on this.

1. I finally caved in and deleted my OpenDirectory master, and am in the process of recreating it.

2. Rather than placing networked users' home directory under /Users, I created a new directory -- /NetworkUsers -- and shared that.

The combination of these two things appears to have worked -- I can login correctly with newly-created user accounts (as before), and their home directories are getting mounted properly. I'm a bit skeptical that step #2 (above) is fully required, but I wanted to be absolutely certain.

I am getting frequent messages (while logged in as a non-admin user) to repair Library permissions, which is a bit odd, but overall, the smbfs mounts are working.

A bit more info on bullet #2 -- I may have actually hit on a solution that others have tried (without knowing it).

The following discussion link has a few people mentioning that this is exactly what they did (create a new directory, share it instead of sharing /Users):

https://discussions.apple.com/thread/5506073

I'm still sporadically having trouble where mounts work, but then have strange permissions issues, or they stop working if I log out and log back in. My next step is going to be to disable SMB, and move entirely to AFP for home directories, and see if that helps.

And, I have (what I hope) is a final update.... I got everything working. But, it required me to reinstall the latest 10.9 server OS on my mac mini. (Doing so was reasonably painless -- hold CMD+R during boot, and the installation can be performed over the web.)

Here are the details of my experience:

- When I purchased my Mac Mini Server in October 2013, it came with 10.8. I upgraded it to 10.9 right away.

- I faced issues with LDAP where I could authenticate at the prompt but couldn't get "Other" to appear in the login window -- this seemed to be caused by an FQDN DNS setup problem which I fixed.

- Once authenticated, I had troubles with users mounting their home directories. Kerberos tickets were getting issued, but for some reason, mounting permissions didn't exist for the users. Ultimately, deleting my OD master and recreating it on the server resolved this.

- Using SMB, logged-in users' home directories were getting corrupted. The kernel was issuing FindFileRef PID=0 errors (which, as Linc mentioned in a post elsewhere, suggests a harddrive problem). It was not a hard drive issue, but bizareness in the network protocol -- unmounting the smbfs directories stopped the kernel from issuing the error. Of course, this meant that the network users couldn't remain logged on...

- So I switched to AFP, which solved this problem, but which led to other issues -- specifically, ACLs on my users' directories weren't getting setup right, so the server was constantly denying read/writes to certain files, even for freshly created users.

I was pulling my hair out, and about to pull the plug. (I was *this close* to abandoning my plans of a single-sign-on solution for my household.) As a last ditch attempt, I learned of the mac restore option (CMD+R during bootup). Before rebooting, I deleted my OD master, removed all shares, deleted all users, repaired disk permissions, and then rebooted with CMD+R. I reinstalled the latest "fresh" Mac OS 10.9 on my Server. I recreated the shares, created a new OD master, created the users, reconfigured the clients...

And everything now works. How? Why? I have no idea. It bothers me that I have no iea what the OS install did to solve my problems. It's opposite to my previous unix experience, where the idea is that you should never have to reboot the machine or reinstall software -- you can, theoretically, fix everything simply by changing the proper configuration files. So I feel like a bit of a failure in the case of my Mac system ... but, well, at least it's working... and that's nice.

I wanted to provide a bit of an update on this, since it has been a while, and I have since developed quite a bit of experience on the topic of "mobile user" accounts.

To put it simply, the bulk of my problems were largely tied to the fact that I was running all of my user accounts as "mobile accounts" (with network-mounted home directories).

Several applications have a hard time dealing with network-mounted home directories. (I've run across a variety of problems with Dropbox, 1Password, Steam, Battle.net, etc. 1Password works, but corruption of the SQLite database happened pretty regularly. Parallels run on a network-mounted home directory was an almost guaranteed way to crash the machine.)

On a practical note, the user experience is pretty miserable. Only 1 network user can be logged in to a mac at a time, generally. The client machines cannot go to sleep, or else they may never resume from sleep correctly. (Oftentimes, OS X hangs while attempting to remount the network user's home directory.) The constant communication with the server leads to significant lag both at the user & server ends. My server would actually crash on a reasonably regular basis -- frequent kernel panics where only a hard reboot would solve the problem. In one case, I watched as OS X Yosemite's kernel ethernet driver died on the server, and then entered into an infinite loop where it reloaded the driver, killed it, and happily logged this all to disk for hours...

In the end, I switched all of my users to "local home directories", with network shares. The improvement in stability -- both at the client and server sides -- was astonishing. My Mac systems went from being very shaky (uptimes typically less than a few days) to being very robust, and I'm back to 99%+ uptime, as I used to have with my previous Linux environment.

The lesson learned, here, makes sense (in a "duh, I should have realized this" sort of way): the amount of caching, temporary file-writing, and so on, which occurs in each user's home directory simply makes mounting them over the network implausible. Having network shares (so that important documents can be stored on the server, but otherwise, configurations are stored locally) solves most of these problems.

Thanks for your update. It was very helpful as I have been having the same issues with my networked home directory users.

Did you recreate all new accounts to make the change to locally stored home directories or were you able to just make the change in the server app for each user?

I have the same issue. I'm trying to run Network Home folders, but when the Mac goes to sleep it losses it's connection.

This is a seriously problem that I;m not why why with Yosemite 4.0 server that this was overlooked? Did not one developer see this and try to resolve it. I know in a Microsoft environment this is not an issue. Apple should really fix this as this can be a great option to have for security reasons.

I know have to switch users to Local directories. Hopefully Apple will resolve this with an update.

Did you recreate all new accounts to make the change to locally stored home directories or were you able to just make the change in the server app for each user?

I just switched them to locally-stored home directories (using the server app).

Then, I provided instructions to users for how to access (using Finder) their original networked home directory on the server, so that they could mount that directory at login and store stuff on the server.

This approach has worked flawlessly. My client computers can go to sleep, wake up, and nothing freezes. My uptime has been 100% since making this change over a month ago. Network traffic is also dramatically decreased.

In short, it is quite clear to me that this feature is very poorly tested, and should probably be removed, given how likely it is to cause hard-to-diagnose crashes and other issues.