Start a Conversation

Unsolved

This post is more than 5 years old

1319

March 15th, 2013 09:00

symlink not resolving outside of AD domain?

I've inherited an NS40 configured by a previous admin.  I believe the previous admin moved the files at the root of this share into another directory, to match another DFS share on the box.

home.png

From Windows, when I look at the root of a this export, there's a Windows shortcut that points to another directory (called 'sharedfs') on the same fs (see screenshot).  For users in our AD, this shortcut always works, and users can traverse it just fine.  Now, I have users in another domain (with a one-way trust) that I need to migrate their files.  When those users mount this share and click the shortcut, they get 'Access Denied'.

Anybody ever encounter this?

Thanks!

Karl

2 Intern

 • 

467 Posts

March 15th, 2013 09:00

Do they have effective permissions to the folder in question?

I'm usually more in favor of creating a seperate cifs server which joins to the new domain rather than relying on domain trusts.

You could also try moving it to a different OU in the domain if it's in the Celerra OU.. that may not be part of your one-way trust.

Also check if the users in question on in the user mapper db.

3 Apprentice

 • 

1.2K Posts

March 15th, 2013 14:00

Thanks, Mark - that's a good starting point.  The directory is open to Domain Users, I don't start with other permissions until level lower.  My test user is a Domain Admin who made himself an account on the trusted side.  He can connect to the share, and the shortcut says it has Traverse folder, List Folder, Read attributes and Read extended attributes.

2 Intern

 • 

467 Posts

March 15th, 2013 15:00

Interesting.  Is there a firewall blocking kerberos? Also look for the user in the usermapper db and see if it was created:

server_usermapper server_2 -Export -user /home/nasadmin/users.export


Look in that file for that user and see if it has an SID.

4 Operator

 • 

8.6K Posts

March 16th, 2013 03:00

Can the test user access the destination directory directly without the symlink ?

3 Apprentice

 • 

1.2K Posts

March 19th, 2013 06:00

Thanks, Mark - I was just thinking about usermapper the other day.  I have a meeting Thursday afternoon EST to meet with the user and do some testing.  I'll grab the usermapper output and see if the user was created.  I believe Kerberos is being passed through the firewall, as I think it's necessary for the AD trust to work.  The user can reach the root of the share, which makes me believe Kerberos is good to go.

3 Apprentice

 • 

1.2K Posts

March 19th, 2013 06:00

Good question, Rainer - I have a meeting with him Thursday afternoon EST to check that out.  I'll try and do a packet capture, while I'm at it, to see if I find anything interesting there.

4 Operator

 • 

8.6K Posts

March 19th, 2013 07:00

I dont think its a problem with the symlink itself - rather with not having access to the destination directory

Do you realize that "Domain Users" only means other from that specific domain and not from the trusted domain ?

see  http://support.microsoft.com/kb/243330/en-us

Note that the Domain users WKS includes the domain RID

SID: S-1-5-21domain-513
Name: Domain Users
Description: A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default.

3 Apprentice

 • 

1.2K Posts

April 9th, 2013 07:00

Thanks, Rainer - we've been able to reproduce this consistently, so we're working with the AD admins.  Now, we've observed that when logging we use our local AD credentials remotely (on trusted servers in the remote AD), we get the same behavior.  Is this still related to the same ACL, or does this expose a different problem?  Thanks again for your help so far - it's invaluable!

Karl

No Events found!

Top