Thanks for this Matt. I'm sure that this will be useful for others.
As noted elsewhere, I've removed your duplicate posts and mildly edited the one I left.
Re the user mappings on your Fileserver, FWIW our Fileserver uses a Samab3 style config which maps Samba users to Linux users. Historically, the automation of the synchronisation of that was handled by a samba module that plugged into the Linux user management system. However it was since discovered that there was a security issue with that module and Samba are no longer maintaining it, so it is gone...
My understanding is that Samba4 style config (as default on the domain controller appliance) uses a single Linux user account to contain all Samba users. However for that to work. it requires filesystem ACLs (they allow additional info beyond the basic Linux file permissions system).
So I may be incorrect, but AFAIK, on your fileserver, you have 2 options.
1. Manually create all your users on the fileserver (both Samba and Linux). Obviously that will only work in a home type environment where you will rarely need to add additional users. In an SMB environment it's probably sub-optimal. Also note, that if any of the Linux users are used (e.g. SFTP), that passwords will not be auto synced. So if a user changes their Windows/Samba password, that will not automatically update the password of the Linux user. This may not be an issue, but I wanted to raise it. TBH, I forget what implications that may have for the fileserver files webUI.
The other option would be to enable ACLs. TBH, I'm not 100% sure how to do that on an LXC guest, but I do know that it will depend on support from the host (I.e. the LXC host appliance will need to have them enabled). You may also need to manually add something to the LXC guest config file to pass them through to the guest. Hopefully google will assist there...
Please share if you find anything interesting and/or useful. Alerting other users is really helpful and may also give us ideas of stuff which might be useful to pre-configure in a future release.
Great work Matt!
Thanks for this Matt. I'm sure that this will be useful for others.
As noted elsewhere, I've removed your duplicate posts and mildly edited the one I left.
Re the user mappings on your Fileserver, FWIW our Fileserver uses a Samab3 style config which maps Samba users to Linux users. Historically, the automation of the synchronisation of that was handled by a samba module that plugged into the Linux user management system. However it was since discovered that there was a security issue with that module and Samba are no longer maintaining it, so it is gone...
My understanding is that Samba4 style config (as default on the domain controller appliance) uses a single Linux user account to contain all Samba users. However for that to work. it requires filesystem ACLs (they allow additional info beyond the basic Linux file permissions system).
So I may be incorrect, but AFAIK, on your fileserver, you have 2 options.
1. Manually create all your users on the fileserver (both Samba and Linux). Obviously that will only work in a home type environment where you will rarely need to add additional users. In an SMB environment it's probably sub-optimal. Also note, that if any of the Linux users are used (e.g. SFTP), that passwords will not be auto synced. So if a user changes their Windows/Samba password, that will not automatically update the password of the Linux user. This may not be an issue, but I wanted to raise it. TBH, I forget what implications that may have for the fileserver files webUI.
The other option would be to enable ACLs. TBH, I'm not 100% sure how to do that on an LXC guest, but I do know that it will depend on support from the host (I.e. the LXC host appliance will need to have them enabled). You may also need to manually add something to the LXC guest config file to pass them through to the guest. Hopefully google will assist there...
Please share if you find anything interesting and/or useful. Alerting other users is really helpful and may also give us ideas of stuff which might be useful to pre-configure in a future release.