How to get the name of the windows default user group

The security mechanism is completely down to permissions on files and programs such as nfsd that run as root (overriding file permissions) and maintain their own security mechanisms. Permissions on the block device files determine whether a user can mount that device. Every file has three sets of permissions (read, write, execute) for three classes of users (owner, group, world), plus a handful of special bits discussed below.

In the 'everything is a file` unix tradition the raw devices and exported volumes appear as special files with file system permissions. Remote mounting remote volumes is a little more complex and is discussed below.

If the user is logged in as the same uid as the owner of the file, then owner permissions can be used. Each user has a default group, and can be added to group entries in the /etc/group file. When a user has access to a group the file permissions for the group are used. Otherwise the user has 'world` permissions. ACL's (Access Control Lists) can be used to grant permissions to specific users where they are available.

Programs can override user level security by having the setuid bit set on their inode entry. This runs the program with the privileges of the owner of the binary rather than the privileges of the logged in user. Examples of such programs are nfsd, mount and sudo. These programs have their own security mechanisms; for example sudo has /etc/sudoers that is used to govern permissions.

mount and nfsd work based on uid and gid, which must be in sync on both machines (often traditionally done via NIS). nfsd has a file called /etc/exports which has the exported file systems and some permissions data. mount and its nfs drivers present credentials which nfsd uses to authenticate the user's right to mount the volume. On a local volume mount uses the file permissions of the block device.

My approach is to not use file/directory level file permissions; use file share level permissions, and set the whole server filesystem data drive to Everyone Full Control (which becomes moot).

Over the years (10+), I have found that NTFS permissions are more complex and leads to more errors. If the permissions are set wrong, or the inheritance gets broken, you expose data and its hard to find and see it. Plus, you are exposed to the move/copy problem as you say.

Places where you have to use directory/file level ACL's; I know of no other solution than health checking the thing on a regular basis.