4

I have a raw copy of a Windows NTFS volume on my Linux machine. When I loop it and share it out on a domain-joined Linux machine via Samba as-follows --

[global]                  
        workgroup = <my-domain>
        realm = <my-domain.com>
        server string = %h (backups)
        security = ADS                         
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        restrict anonymous = 1
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        usershare allow guests = Yes
        allow insecure wide links = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap uid = 10000 - 20000
        idmap gid = 10000 - 20000
        winbind enum users = Yes
        winbind enum groups = Yes
        idmap config * : range = 10000 - 20000
        idmap config * : backend = tdb
        map acl inherit = Yes
...
[TestShare]
        path = /datto/mounts/TestShare
        valid users = nobody
        read only = No
        create mask = 0755
        force create mode = 0755
        force directory mode = 0755
        veto files = /lost+found/.locate.db
        dfree command = /datto/bin/dfree-runner

There are no longer permissions associated with the block device (left -- right, original).

left -- no permissions on share. right -- original permissions.

On the other hand, mounting an iSCSI target of that same volume shows the original permissions.

Is it possible to serve these original permissions / securities over SMB? If so, is there something I can add or modify in my configuration of this share?

1 Answer 1

1

I'm not exactly sure why this happens but NTFS permission do not translate to *nix very well. I'm pretty sure that the on disk permissions that NTFS (5.0) uses are MUCH more complicated than what SAMBA reads. In my experience with connecting something like MacOS or BSD/FreeNAS to a device with NTFS on it, if you have a disk that has permissions applied that are for a non-domain joined computer and it is an OS disk, it will generally appear to work relatively normally (you can't get into C:\Users\%username% until you reset, but a folder on the C: root will have the permissions as 'Everyone'.) If you have a computer that is domain joined, things get quite harry. The extra SIDs that are domain\username likely require you to connect that *nix box to the LDAP service of the domain at a minimum. Even then, I have had trouble getting them to work smoothly.

I'm guessing from your screenshots that you don't have a domain there (computername\username) so your issue is likely pseudo related to a need for an LDAP connection (SID syncing). You could probably resolve this issue by either validating the permissions that are applied to the NTFS with a user that is synced to LDAP on your *nix box or standing up a Windows Server and connecting to that with LDAP or something like that. That is at least the path you want to drive down. =P

2
  • My domain is bjd2385.com, so in the right window, such a user would be bjd2385\Administrator. Thanks for your reply!
    – bjd2385
    Apr 28, 2019 at 21:15
  • Ah, yes. If you're domain joined then your SID is not replicated to the disk with anything meaningful. It's just a SID. There's also much more complex permissions in NTFS than *nix can manage when you have a Windows domain. You need LDAP for syncing the SIDs and then you'll still want to actually SET the permissions on a box that is running Windows so that it propagates the permissions properly. Apr 29, 2019 at 0:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .