CIFS share, ad domain, can't see user created dirs

[gsloop]

So, I've seen several threads about this, but can't seem to find a way to resolve it. [None of the discussions I saw really discussed what fixed it, if anything.]

I most notice [find it annoying] in profiles.
FreeNAS is joined to a Samba 4 AD domain.
I'm using domain users/groups for ACL control/access.

At the root of the roaming profile directory, the general starting ACL's are as MS recommends. [Inheritance is off.]
Admin, domain admins, system have full control.
Domain users has the rights (in this folder only) to
---
Traverse folder
Read Att
Read Ext Att
Create Folder
Read permissions
[I also set Write att / Write ext att - because of some of my testing. Not sure if I'm granting excessive rights or not.]
---

Creator owner (in sub folder and files)
Has full control

---
Now the problem.
When the user logs in - the GPO has the users system work to create a folder for their roaming profile [/mnt/some-freenas-path/%USERNAME%]
They have the rights to create a folder and that succeeds.
They then become the owner, and thus have full rights to the folder.
This all works great. The profile gets stored and appears to be held properly and read back to the machine the next time it logs in.

However a user with Administrator/Domain Admin privs can't see the directory or any of the files created by the user, while setting up the profile.
Logged in to the console at the CLI a "ls -al /mnt/some-freenas-path/" shows it all there.

Is there a known good method for setting the ACL's so the admin equivalent accounts can see these directories/files?
[I'll be perfectly glad to document it all, and write up a how-to, if someone can help me work my way through this.]

-Greg

 

[dlavigne]

Were you able to resolve this? If not, which FreeNAS version and which Windows client versions?

 

[gsloop]

I'm sure you posted this a few days ago, and I'm sure I replied then too...

[Edited]
Ah, I see you posted on another very similar thread - documenting my initial foray into solving this problem. I will note that I got to a place where I had a bunch of corrupt profiles and that wasted a bunch of time trouble-shooting. They'd fail to store/save or restore on a PC. I was using a single PC as my test-bed. After looking at the logs in FN, Windows and the Samba controllers, it sure seemed the problem was with the station. Setup a new station with new profiles, deleted the "old" profiles and started fresh - and the problem of profiles not storing/restoring went away.

I still had/have the issues mentioned in both threads, that the permissions of the profiles directories are not visible in Windows to ADDC Admin equivalent users - even though they should have full permissions. And this problem persists still.

So, just beware that the local profile on the station can get so corrupt it won't store or accept an update from the roaming profile that's supposed to be working. This vastly complicates the search for a solution! :)
[/Edited]

But to repeat.
No, I've found no way to change the ACE's or Windows permissions using Windows tools that solves this problem.

I've spent a lot of time trying - and I can't continue to dump days or weeks into it any more. [My sanity was not doing well either.]
I'm pretty sure there's a way to accomplish it with ACE's, but I know so little that the attempt mostly devolves into more-or-less randomly flipping switches and just hoping it fixes something.

As noted, I can work with anyone who has some good ideas as to how to solve this - that environment is now in production and we're just living with the undesirable problems. While being able to manage things with Windows would be far better, one can always use something line WinSCP and work around it. But it's certainly messy, a kludge and really stupid - if one could find a way to solve the problem.