SOLVED SMB mapall equivalent?

[virtualdxs]

Is there a way to force all writes on an SMB share to be written as a specific user/group, similar to NFS's mapall user/group?

 

[anodos]

Is there a way to force all writes on an SMB share to be written as a specific user/group, similar to NFS's mapall user/group?

force user
force group

another parameter to investigate would also be inherit owner

 

[virtualdxs]

Thanks for the response. Where do I put those options? Nothing jumps out at me. Auxiliary parameters maybe?

 

[anodos]

Thanks for the response. Where do I put those options? Nothing jumps out at me. Auxiliary parameters maybe?

Yes. Under services->SMB.

 

[virtualdxs]

Will it not work if put under a specific share?

 

[virtualdxs]

I just tested; it does work under a specific share! Now I'm running into one other issue: the GID on FreeNAS doesn't match the GID on Linux, so either I set the group to the AD-linked group and have it work on Windows and not Linux, or I set the GID to the correct one with a fake account on FreeNAS (w/ manually set GID) and it works on Linux and not Windows. Is there any chance this feature request could be implemented?

 

[anodos]

Is there any chance this feature request could be implemented?

No, but it's not required for making the idmapping consistent. Just adjust the low range for rid to match one for SSSD.

 

[virtualdxs]

No, but it's not required for making the idmapping consistent. Just adjust the low range for rid to match one for SSSD.

That's perfect, thanks! I was under the impression they used completely different algorithms.

Unfortunately it seems to not be working. I went to AD -> Edit idmap, set the range low to 1680000000, and set the range high to 9999999999. Despite this, `getent group db_admins` still returns `db_admins:x:21267`. Any ideas? Thanks a ton for your help.

Edit: Disable FreeNAS cache is on, and UNIX extensions are off.

 

[anodos]

and set the range high to 9,999,999,999.

That's a 32-bit integer. Don't go that high. 2,000,000,000 is probably fine.

Code:

service samba_server stop
rm /var/db/samba4/winbindd_cache*
service samba_server start
net cache flush

 

[virtualdxs]

That's a 32-bit integer. Don't go that high. 2,000,000,000 is probably fine.

Code:

service samba_server stop
rm /var/db/samba4/winbindd_cache*
service samba_server start
net cache flush

Sorry for taking so long to get back; I only work at this job Mondays and Fridays. So I followed your advice and set the high to 2,000,000,000 and flushed the cache, and now I'm getting db_admins:x:90000008. That shouldn't be possible, as the range min is 1,680,000,000. Any ideas what's going on? Flushed the cache again (and by flushing the cache I mean running the 4 commands you provided) doesn't fix it.

 

[virtualdxs]

If it helps, id dxs gives me uid=90000001(dxs).

Looking at it more, it assigns UIDs based on the order in which I query them. Shouldn't this not be happening with rid?

 

[anodos]

If it helps, id duncan gives me uid=90000001(duncan).

Looking at it more, it assigns UIDs based on the order in which I query them. Shouldn't this not be happening with rid?

UID 90000001 is in the range for the default idmap backend for winbind. It sounds like your idmap settings are misconfigured (or this is a trusted domain). Try removing winbindd_idmap.tdb and repeat the cache clear. (back up the idmap.tdb first).

 

[virtualdxs]

I got it working right before you posted that :)

A random combination of running the commands you gave and enabling/disabling from the GUI fixed it. Thank you for all your help!