I mean at first glance of course naming it with a dollar sign $ will administratively hide it. But I'm guessing you know that. Are you trying to access it via \\smartconnectzonename.domain.xyz\test$ and it's not working? Then odds are pretty good that it's an NTFS permissions issue. That said your path is /ifs, and NEVER put NTFS ACLs on /ifs, you'll probably break the cluster. Are you just trying to allow yourself as an administrator to browse the tree? Then give just your admin account run-as-root rights to the share. Be extremely careful with how you use this because as the name implies it gives you effectively root access over SMB. While useful for administrative purposes or for data migrations, it can be a real mess if you ever put that on a user-facing share.
Yes, I am intensionally hiding the share. I am trying to access it via \\[SERVER.DOMAIN.xyz]\test$ and its not working. I have no plans to add NFTS permissions to /ifs and was hoping I wouldn't have to. Yes, per the instructions for the Isilon Search tool, I need to give it permissions to access the share for /ifs. Isilon Search don't require a run-as-root right to perform this task of scanning the entire filesystem.
I will verify the SPN isn't an issue and reply to this tomorrow morning.
crklosterman
450 Posts
0
April 18th, 2017 13:00
I mean at first glance of course naming it with a dollar sign $ will administratively hide it. But I'm guessing you know that. Are you trying to access it via \\smartconnectzonename.domain.xyz\test$ and it's not working? Then odds are pretty good that it's an NTFS permissions issue. That said your path is /ifs, and NEVER put NTFS ACLs on /ifs, you'll probably break the cluster. Are you just trying to allow yourself as an administrator to browse the tree? Then give just your admin account run-as-root rights to the share. Be extremely careful with how you use this because as the name implies it gives you effectively root access over SMB. While useful for administrative purposes or for data migrations, it can be a real mess if you ever put that on a user-facing share.
The other possible issue is an SPN issue.
'isi auth ads spn check --domain=domain.xyz"
will show you if you have any SPNs missing.
Hope it helps,
Chris Klosterman
Principal SE, Datadobi
chris.klosterman@datadobi.com
chjatwork
2 Intern
•
356 Posts
0
April 18th, 2017 16:00
Yes, I am intensionally hiding the share. I am trying to access it via \\[SERVER.DOMAIN.xyz]\test$ and its not working. I have no plans to add NFTS permissions to /ifs and was hoping I wouldn't have to. Yes, per the instructions for the Isilon Search tool, I need to give it permissions to access the share for /ifs. Isilon Search don't require a run-as-root right to perform this task of scanning the entire filesystem.
I will verify the SPN isn't an issue and reply to this tomorrow morning.
Thank you,
chjatwork
2 Intern
•
356 Posts
0
April 19th, 2017 06:00
Ok this is what I got:
SERVER-2# isi auth ads spn check --domain=DOMAIN.DOMAIN.xyz
Missing Service Principal Names:
nfs/SERVER3
nfs/SERVER.DOMAIN.xyz
nfs/SERVER-nfs.DOMAIN.xyz
nfs/SERVER-mgmt.DOMAIN.xyz
Additional Service Principal Names:
HOST/SERVER1
HOST/SERVER1.DOMAIN.xyz
SERVER-2# isi auth ads spn list --domain=DOMAIN.DOMAIN.xyz
SPNs registered for SERVER3$:
HOST/SERVER-mgmt.DOMAIN.org
HOST/SERVER-nfs.DOMAIN.org
HOST/SERVER-mgmt
HOST/SERVER-nfs
HOST/SERVER.DOMAIN.org
HOST/SERVER
HOST/SERVER1
HOST/SERVER1.DOMAIN.org
HOST/SERVER3
HOST/SERVER3.DOMAIN.DOMAIN.xyz