This post is more than 5 years old
7 Posts
0
3113
Strange behavior on files and dir created from Windows.
Hi all,
first post here so apologize for every error I could make.
I have an isilon cluster where I'm studying and I've noticed a very strange thing ( in respect to what I see on some "made by other" isilon clusters).
When looking at files created by windows on a SMB share here is the output:
IsilonTest-1# ls -l
total 68
-rwxrwx--- + 1 1000006 1000008 9 Apr 9 14:46 New Text Document (2).txt
-rwxrwx--- + 1 1000006 1000002 49 Apr 9 14:41 New Text Document.txt
As you can see, the UID and GID is numeric, while I have seen this in other cluster with their original names.
If I look at my authentication providers everithing seems fine, but eventually is not:
IsilonTest-1# isi auth status
ID Active Server Status
----------------------------------------------------------------
lsa-activedirectory-provider:PIGI.PRIV Pigi-AD.PIGI.PRIV online
lsa-local-provider:System - active
lsa-local-provider:TestAccessZone - active
lsa-local-provider:pippo - active
lsa-local-provider:ThirdAccessZone - active
lsa-file-provider:System - active
----------------------------------------------------------------
Total: 6
IsilonTest-1# isi auth ads view PIGI.PRIV
Name: PIGI.PRIV
Status: online
Primary Domain: PIGI.PRIV
Forest: PIGI.PRIV
Site: Default-First-Site-Name
NetBIOS Domain: PIGI
Hostname: isilontest.pigi.priv
Controller Time: 2018-04-09T17:36:52
Machine Account: ISILONTEST$
Groupnet: groupnet0
I have some suspect, but would like to initially discuss about this without talking of it, just to not give false ideas .
What, in your experience, could cause such behavior ?
Thanks in advance
Pierluigi
P_frullani
7 Posts
1
April 11th, 2018 06:00
I have finally managed to understand which was the problem.
Every check from the troubleshooting guide was OK, so I need to "open the mind" and look better.
The problem was that in the "System" zone was missing the Active Directory provider.
I have then modified the zone to use also the ADS provider and now everithying is working as expected:
IsilonTest-1# ls -ltra
total 18
drwxrwx--- + 2 group PIGI\domain users 0 Apr 5 19:12 OkShare2
drwxrwx--- + 3 group PIGI\domain users 24 Apr 5 19:30 OkShare1
drwxrwx--- + 2 group PIGI\domain users 0 Apr 6 09:18 home
drwxrwx--- + 2 group PIGI\domain users 0 Apr 6 09:31 MultiRightShare
drwxrwx--- + 2 group PIGI\domain users 91 Apr 6 12:55 sharedup
drwxrwx--- + 7 group PIGI\domain users 133 Apr 7 09:09 .
drwxr-xr-x 3 admin admin 27 Apr 11 09:11 ..
Thanks to all for your help ! It has been really important !!
Pierluigi
chjatwork
2 Intern
2 Intern
•
356 Posts
0
April 10th, 2018 03:00
Knowing this will help with the troubleshooting process.
P_frullani
7 Posts
0
April 10th, 2018 05:00
Chris,
thanks for your answer, and my bad for not giving such information in first post.
1. Onefs is 8.1.0.0 ( I'm using the isilon on virtual machines, as study environmnent )
isi version says: Isilon OneFS v8.1.0.0 B_8_1_0_011(RELEASE)
2. I haven't check for patches.
3. 4. AD Windows is win2012 R2 DataCenter ( not patched )
5. I have three nodes in cluster .
6. As far as I can tell yes:
IsilonTest-1# isi auth ads list
Name Authentication Status Site
---------------------------------------------------------
PIGI.PRIV Yes online Default-First-Site-Name
---------------------------------------------------------
Total: 1
IsilonTest-1# isi auth ads spn check PIGI.PRIV
No missing SPNs found.
Pierluigi
AdamFox
254 Posts
0
April 10th, 2018 06:00
When you see UIDs and GIDs in the 1 million range, this means that OneFS was unable to map the name of the user and/or group to a proper UID/GID. I see that you have multiple access zones so be aware that the mapping is done on a per access zone basis so while all of your providers are active, they must be properly assigned to each zone as appropriate for your environment. The cluster will use the providers assigned to the specific access zone being accessed by the end user to do a match. This is important because the System zone can see all of the cluster, so if you map a share through the System zone, it's possible to access data in a different access zone, but you will be using the System zone authentication providers in that case which could cause a mismatch. I'm not saying that's what's happening here, but it's just one possibility of an improperly mapped user/group. There are certainly other ways this can happen though. But my goal here is to hopefully set you on a path to find our your specific mapping issue.
P_frullani
7 Posts
0
April 10th, 2018 11:00
My bad, again.
I should also explain better how I'm configured.
There are a bunch of access zone, but they are only tests. Not using any of them, except for "TestAccessZone".
The ADS provider is defined in "global" configuration and used only in TestAccessZone.
The only real zones are the System and the TestAcessZone.
Peter_Sero
1.2K Posts
1
April 11th, 2018 04:00
Have a look a the relevant trouble shooting guides from this page
Customer Troubleshooting - Isilon Info Hub
In particular,
Troubleshoot Identity Mapping
uid1
8 Posts
0
February 26th, 2020 14:00
Hi, I'm sorry I did not understand "the zone was not using the provider". You listed it out and the system zone was active. Where is the command to find if the system zone is using the provider? Sorry, I did not follow this.
RobRyan123
2 Posts
0
September 18th, 2022 11:00
Thanks for the tip!. My issue wasn't the same as yours, but adding AD to the system zone resolved my problem.
Cheers!!