Hahahaha! U got me. Fake news, all fake news!!! 
4 Likes
Version #2
Reworded “special privileges” section. Adding more checkboxes could be easier in the future…
@flatspin: this is a mockup too 
1 Like
What is the difference between option 1 and option 2 for special privileges ? They seem the same ? Is the home$ folder conflated here with profile ?
The profile folder will contain the bare minimum from the profile. (that which can not be redirected to the home folder). Included would be AppData\Roaming and the NTUSER.DAT but not folders like 'My ’
The home folder should be seen as ‘private’ server storage for the user and through folder redirection, the documents and other relevant 'My ’ folders get redirected there.
For the home folder, the user needs full controll IN it, but ownership is irrelevant. For the profile folder, either Domain Admins or the user should be the owner. Notably the last one has been proven difficult for me to setup.
There’s no difference in implementation. The comparison purpose is to evaluate the effectiveness of the text labels: are they comprehensible, self-explaining, clear enough? What option do you prefer? Do you want to suggest an alternative?
Sorry, but roaming profiles are not planned in this feature! We should discuss them in another thread.
For the special permissions I would use: ‘Grant full control on shared folder to Domain Admins group’
There is no special case on a home share that would make it logical to set Domain Admins with full control there, so imho it shouldnt get a special mention as it will confuse people into thinking they need this permission for a home share.
If this permission IS needed due to implementation reasons, then it would need the first message, but we would also need to know why to understand the implications and possible limitations.
This is the rationale provided by @GG_jr that seems reasonable
samba-audit could also plug its configuration to provide audit logs about home$ (ab)use too…
That actually will not pass the GDPR. The sysadmin should be able to GET access at all times. Not HAVE acces at all times. Therefore, ownership is much more interesting then actual userrights assignment.
Yes this scenario you mention can be usefull, but therefore I would not name add the (home$ share) reference to the mentioning of the option.
1 Like
Could you make an example? How should it work?
Normally, the sysadmin appoints a group that has ownership, or as only right, the right to change permissions (and thus add rights). Ownership is a bit nasty, it will mess up permissions. The right to change permissions requires better logging to avoid people doing unauthorized things.
When procedures require the admins to access shares they give themselves, the auditors, or whomever the required acces, but this is then logged.
Afterwards they resore permissions to a state where only those users that require access to the share for their work have access, and admins are able to add rights.
User rights (change):
Admin rights:
1 Like
As the smb.conf man page recalls…
In a POSIX filesystem, only the owner of a file or directory and the superuser can modify the permissions and ACLs on a file.
Even if Samba can emulate the “multi-owner” feature of Windows, our NethServer inherited the Posix ACL way and we cannot change it now. So in NS only root or the file owner can change the file permissions. With admin users option, root privileges can be easily granted to members of “Domain Admins” (or any other user/group).
We could implement a new shared folder profile flavor with Windows ACL in the future though.
What could happen in NethServer is:
The Domain Admins log on Server Manager, enable the special permissions perform privileged operations, then disable special permissions.
Is it acceptable?
1 Like
It’s deffinately workable, yes.
What is preventing us from mounting the filesystem with extended atrributes, and enabling Windows ACL’s ? SAMBA4 supports it out of the box, the needed modules are already loaded and afaik the only thing missing in the chain is the filesystem being mounted the correct way for this to work ? (On my ToTest list … )
If we implement permissions at the Windows/Samba ACL level we actually implement a permissions layer over the filesystem that is visible only to SMB clients. In other words if an user access to files with SCP or NFS the Windows ACLs are not enforced.
A similar situation happens with Dovecot. IMAP ACLs are implemented by the IMAP server. Everything under /var/lib/nethserver/vmail is owned by vmail user (dovecot). As long as everyone accesses mail through IMAP, ACLs are effective.
We can implement Windows ACL only if Samba is the only service that can access shared folders.
IIRC XFS (the default CentOS7 filesystem) has extended attributes enabled by default
1 Like
We’re all here to listen to each other. Good idea will be implemented eventually 
…make that: rather quickly
The prototype implementation can be installed with the following command: /cc @flatspin
yum install http://packages.nethserver.org/nethserver/7.4.1708/autobuild/x86_64/Packages/nethserver-samba-2.0.10-1.5.pr23.g3267e60.ns7.noarch.rpm
1 Like
The netbios name can be set and works correctly. Host is shown in windows network neighborhood.
Control and privileges not shown. Not yet implemented?
Installation: NS7 with LADP and file server.
1 Like
As in the shared folders interface, those controls are not available with LDAP accounts provider. Do you think we should display a note?
o.k. with AD it works.
Just for my personal knowledge: why doesn’t the control feature work with LDAP?
Yes, and a short explanation in the inline help.
Another suggestion: This is strongly connected to the shared folders. What about adding this as a tab to the shared folder section?
Yes, I’d add to Shared Folders page
- a “Configure” button that points to the Windows file server page
- the warning message if accounts provider is LDAP
3 Likes
And here is my explanation: I didn’t think about the restriction of guest access only with LDAP. 
Thank you Davide.
2 Likes