Mac files to Windows server not inheriting permissions correctly...

[Koldov]

TL;DR - The Headteacher uses a Mac... transferring files to a folder on Windows server share does not inherit the correct permissions.

 

We have a Performance Management folder on a Windows 2012R2 server.

 

The Headteacher has been putting files into these folders for a couple of years with no issues.

 

The SLT have full control on all folders (inherited from the top folder, with Authenticated Users having Read access) and then the individuals have full control on their own sub-folders (also Access Control is enforced).

 

Today I have been informed that teachers now cannot see the files the Headteacher is putting in there, although this appears to have only just started happening and files from Windows pick up the permissions correctly... also it appears that older files are OK and files modified today are not.

 

Looking at the permissions, the files usually pick up these permissions:

 

SYSTEM - FULL

TEACHER - FULL

SLT 1 - FULL

SLT 2 - FULL

SLT 3 - FULL

HEAD - FULL

DOMAIN ADMINS - FULL

SCHOOL ADMIN - FULL

 

Now the new files are picking up these permissions:

 

SYSTEM - FULL

SLT 1 - FULL

HEAD - FULL

SCHOOL ADMIN - FULL

ACCOUNT UNKNOWN (S-1-5-88-33216) - NONE

 

That last one has obviously done the damage and from my research appears to be the SID used for MAC > WINDOWS.

 

Is it some issue with the way the Headteacher is moving a file or editing the file, or something that isn't correct in the permissions (as it has been OK up until now)?

Edited March 15, 2022 by Koldov

[Koldov]

Just to add...

 

I have come across a couple of posts on other forums that seem to be the exact issue!

 

Unfortunately the fix doesn't seem to apply to my situation...

 

So far I have found it appears to be a well-known (and quite old issue with Mac OSX) transferring file to a Windows server.

 

“I have a share on a Windows machine that acts as a server. We have several people on Macs that need to create/modify files on this machine. When one of these people creates or copies a file to the share the file acquires a Windows account with a name like this:

 

S-1-5-88-3-33216

 

This account has no permissions and seems to mess with all the other permissions on the file. The end result is that users can't see the file until I remove this account manually from the file permissions.

 

Has anyone seen this before?”

 

‘You can get around this by removing "Full Control" for "Everyone" at the share level (and possibly the NTFS level) and changing it to "Modify".’

 

answered Apr 10, 2013 at 20:23

 

Also, this:

 

“We have one other mac running 10.13.3 that does not have the issue. All other OSX machines are running 10.12.

 

Problem: When copy and pasting between folders on a network drive, the folder becomes unreadable to all but the user who created it. This obviously creates a lot of problems for that user. The fileserver is windows 2012 server.

 

I was able to reproduce on the other mac with 10.13.3 now. Exact steps are 1) take a network file, on a network drive 2) make a folder on another network drive and copy it there. 3) then select that file that you copied, make another folder on the second drive, and then copy it there. the permissions get set to "everyone no access" and then I can’t even view the file in the preview window. The folder permissions on the parent folder are correct.

 

So it has something to do with copying files between two network folders.

 

I noticed that there is a weird SID on the files I can’t read, specifically S-1-5-88-3-33216 . So on a lark i decided to look it up and found this article which says that this was a problem with share permissions in OSX 10.8

 

So I start playing around with permissions and lo and behold, if I remove the Folder -> Share -> everyone -> Full control (from just the share permissions, not the security tab) it appears that this problem is solved! or at least worked around.

 

So the solution seems to be to remove the full control on the everyone group on the windows share dialog. I am going to test with the user and make sure, but I can’t make the broken file anymore. The everyone FULL CONTROL on the security tab seems to not matter, as with it set the files are not broken.”

 

Mar 29, 2018 11:54 AM

 

Unfortunately we do not have the 'Everyone' permission set on the folder (only on the very root of the main share and I'm wary of removing or altering this)...

Edited March 15, 2022 by Koldov

[Koldov]

Not sure if there is a way around this if the only option is to modify the 'share' permissions as it is only a folder on a share (and it was created with unique 'non-inherited' permissions due to it being 'sensitive')...

 

Currently it looks like this (folder 4 is the problem) :

 

Server SRV-01

Drive E:\

Share STAFF_SHARE$ - Share Permissions = Everyone

Folder 1 MATHS - Inheriting

Folder 2 ENGLISH - Inheriting

Folder 3 SCIENCE - Inheriting

Folder 4 PERFORMANCE MANAGEMENT - not inheriting/permissions set on folder manually - sub-folders inheriting from this

Folder 5 GEOGRAPHY - Inheriting

Folder 6 HISTORY - Inheriting

etc...

 

I have asked the Headteacher to modify their workflow, so as not to include any step of directly copying or moving a file from one network drive/share to another through 'Finder' on the Mac and will have to wait and see if that works...

[5tu]

Share Permissions are different and separate from NTFS permissions.

 

Changing your Share Permissions from "Everyone" to "Authenticated Users" won't affect the granular NTFS permissions you have set.

[Koldov]

Is 'Authenticated Users' the recommended way to share these days (haven't had to create a proper share for years), I was always told:

 

Share Permissions = Everyone

 

NTFS Permissions = '(specify users/groups here to allow access)'

 

Anyway, the solution I found (and I've seen repeated in a few places, but only parrot fashion as it seems a limited set of circumstances produce the issue) is to change (on the SHARE) 'Everyone' permission from 'Full Control' to 'Modify'.

 

Problem is this affected folder is in the shared staff drive (the actual root share), to change permissions on this would affect hundreds of folders and thousands of files on a prod server and I really don't want to mess that up...

 

The other issue that I have is that this folder does not inherit permissions (I presume neither share or NTFS), because it is a 'sensitive' folder. SLT have full control along with admin, staff have read and then all sub folders inherit this and then have the staff member with full access on their own folder (however all folders without this specific permission are hidden with 'Access Control').

[Koldov]

Well, I have done a little more research on this and am hopefully going to be able to answer my own question (and help someone else - although it seems a unique set of circumstances judging by the lack of replies)...

 

I will write a little bit about the testing and configuring of share permissions, but if that is a little TL;DR... Essentially I noticed one major difference between this folder and all the others on the share... in the NTFS/File/Security permissions there was an entry for 'SYSTEM' with 'Full Control' - once this was removed, the corrupt permission disappeared and the correct permissions were applied!

 

I created a test document in a test folder and asked the Headteacher to edit it... they did and it disappeared, so I checked on the server and the permissions had been corrupted.

 

I changed the folder to a share and changed the share permissions but it had no affect (going from everyone 'Full Control', to just modify, to adding 'Authenticated Users' and configuring those, to removing 'Everyone')... nothing changed. Which thinking about it, I'm not sure now why I thought it ever would, as share and file permissions are completely separate (not sure why it seems to have worked for others though)...

 

However, in the NTFS/Security/File permissions I saw the 'SYSTEM' account having full control (I had just replicated the permissions from the original problem folder). It was created a long time ago and I'm not sure why this was present, but I had just recreated the test folder with the same properties.

 

After a little research and checking no other folder on the share had this 'SYSTEM' account in the file permissions, I decided to remove it (as it was only a test folder)... and the test document file reappeared for me on my workstation under my log-in and a check on the server indicated that now the correct permissions were being applied!

 

So the next step is to test that this has completely fixed the issue and apply it to the main problem folder (if I can work up the cojones)...

Edited March 28, 2022 by Koldov

[AntonioRocco]

Only just seen this post.

 

Too late now but I saw something very similar years ago. Ended up involving legacy versions of the server OS being upgraded (rather than clean installs) over successive years. 'Ghost' users/groups with legacy user names (including the system user) had been applied with associated permissions in the past and seemed to be 'glued' to shares/folders. Ordinarily these did not seem to cause any major problems with PC users but once Macs were introduced then oddities like the one you describe began to appear. Once these 'ghost' users/groups with their associated permissions were removed the problems faded away.

 

Not much help now I know as you seem to have figured this out anyway and if it is as you surmise then well done!

 

Antonio Rocco (ACSA)