- This topic has 3 replies, 1 voice, and was last updated 18 years, 1 month ago by
.
-
Posts
-
Ok,
Leopard 10.5.5 running on an iMac in an office environment running Active Directory (AD) on Windows 2003 servers
Using the “connect to Server dialog” to mount a drive ends up showing no files in the mounted volume.
The volume is specified using “cifs://servername/sharename/path-to-folder” and seems to mount the folder as a disk icon on the desktop correctly (that is, it shows up and can be opened) but the user can’t see the contents of the mounted volume in question. Logging in as the affected user on another machine allows him to mount the same folder and see (and edit) contents successfully.
Displaying the preview for the share itself (not the folder within the share) when it is mounted reveals that the network drive was “connected as” another user who does not have network permissions on the folder or drive in question.
The iMac was created by making a disk image and restoring it over the factory install. The user name under which the drive mounts is related to a network (AD) login for the person who created the disk image in the first place, so there may be some lingering data that is causing the drive to mount under that user name.
How do I force the system to use the logged-in user’s name to mount the volume? What files do I need to remove or modify to fix this?
I’m stumped.
peter+dodge wrote:
Ok,
I’m stumped.I’m still stumped, but Josh suggested I take a look at the Kerberos settings to see if it is using a TGT. It is, but it creates a new principal using my credentials when I mount or dismount the volume. I can get the user access if I display (preview) the root volume in columns format and click the disconnect button as the volume remains in preview and the disconnect button changes to allow “Connect as” using the user’s credentials. But only for that session.
Oddly, disconnecting the root volume in any other view drops the connection and disappears the icon from the sidebar without allowing the user to reconnect as himself.
MacTroll wrote:
So this works on another machine? And it’s just one that’s having issues?
it’s just one machine but any cifs:// volume on that machine.
He can mount and access the same volumes from any other Mac in the shop.
MacTroll wrote:
For starters…
Mount the share on a working machine. Use klist or the Kerberos.app buried in the System Folder to see what tickets they got.
On the non-working machine, do the same and compare.
Ugh. Nothing like going back to basics to expose mistaken assumptions.
Mounting a volume on another box to compare kerberos tickets revealed that the logged in user is prompted for username and password. No SSO in effect.
So, a quick check of the keychain on the machine with the problem showed that I had entries for the volumes in question in the user’s login keychain. I deleted this, and voilá, the user’s credentials (read keychain entry) was used to mount volumes and now he can see the contents thereof.
But this means we aren’t getting SSO and I need to look at why that is. (bah, always something.)
- You must be logged in to reply to this topic.