Bind individual SMB shares to different IPs
- Thread starter ARNiTECT
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
The smb server is listening to related ip ports. You cannot have another service listening to the same ports, does not matter if it is in a zone. As there is no option to control singe shares based on ip, you cannot do what you want.
What you can do is to control smb at all based on client ip with firewall rules. You can also have multiple full OS VMs, each on a different ip with its own smb service. Controlling ZFS filesystems with shares is then a problem.
What you can do is to control smb at all based on client ip with firewall rules. You can also have multiple full OS VMs, each on a different ip with its own smb service. Controlling ZFS filesystems with shares is then a problem.
You can have different processes bound to the same port on different interfaces (technically IPs). I'm not familiar with how you would best do that in OmniOS, but if I were doing it on a plain Linux system I'd probably just containerize each instance.
You cannot use several instances of the kernelbased SMB server and bind shares to ip adresses in OmniOS. It may be possible when you use SAMBA in OmniOS with hosts allow und hosts deny. But then you loose ntfs alike ACL, SMB groups with groups in groups, Windows sid as ACL reference and extended ZFS attribute, ZFS snaps as Windows previous version and ACL management from Windows instead configuration in smb.conf.
I'm not saying this would be a good idea, but...
If you had a host with multiple Ip addresses, you could stand up multiple instances of the samba docker container, and share different things on different addresses by binding different instances to different addresses.
hub.docker.com
If you had a host with multiple Ip addresses, you could stand up multiple instances of the samba docker container, and share different things on different addresses by binding different instances to different addresses.
dperson/samba - Docker Image
I would like to setup vlans, but minimise 10Gb inter-vlan routing on the router and avoid getting a 10Gb L3 switch.
I played around with Zones today and just managed to nest OmniOS with napp-it in a zone with its own IP. I passed through a second vnic adapter from ESXi to OmniOS, which is used by a vnic in OmniOS assigned to the new zone. In the new zone, I created a subfolder under pool/zones/myzone/ROOT/smbshare1. I can access this share on the LAN at the IP address of the new zone. I set the nested OmniOS VM to auto-start, I can manage the zone's folders from the top level for replication etc. so it looks like the nested OS wouldn't need much maintenance.
I'm not sure if this is the best method to do what I want to do, but I'll keep experimenting with it.
I played around with Zones today and just managed to nest OmniOS with napp-it in a zone with its own IP. I passed through a second vnic adapter from ESXi to OmniOS, which is used by a vnic in OmniOS assigned to the new zone. In the new zone, I created a subfolder under pool/zones/myzone/ROOT/smbshare1. I can access this share on the LAN at the IP address of the new zone. I set the nested OmniOS VM to auto-start, I can manage the zone's folders from the top level for replication etc. so it looks like the nested OS wouldn't need much maintenance.
I'm not sure if this is the best method to do what I want to do, but I'll keep experimenting with it.
So far, I'm liking the flexibility of zones for this use case.
I have a number of pools on the server, based on NVMe-SSDs, Sata-SSDs and HDDs. I have set it up so that a Zone in one pool can include datasets added/mounted from other pools. So when I access a Zone over the LAN, these specific datasets from various pools are available; this reduces the number of zones I thought I'd need. eg photos on SSDs and videos on HDDs are accessed on a single storage device on a 'Media' VLAN.
I'm setting this up using OmniOS command line. It looks like several Zones features are currently being added into napp-it (My global zone is on 26.dev and the other zones 22.03).
I have a number of pools on the server, based on NVMe-SSDs, Sata-SSDs and HDDs. I have set it up so that a Zone in one pool can include datasets added/mounted from other pools. So when I access a Zone over the LAN, these specific datasets from various pools are available; this reduces the number of zones I thought I'd need. eg photos on SSDs and videos on HDDs are accessed on a single storage device on a 'Media' VLAN.
I'm setting this up using OmniOS command line. It looks like several Zones features are currently being added into napp-it (My global zone is on 26.dev and the other zones 22.03).
Virtualizing the whole OS (container, zones or full OS) with independend SMB services on each instance where each offers different shares with access to the same ZFS pool is always an option. The overhead especially regarding complexity, security and bug fixes is massive.
I noticed clients can't access any smb shared datasets assigned to a zone from the global zone's IP; this is probably for the best.
I hoped there would be minimal impact on memory & cpu from sharing datasets through zones.
It looks like I can do most of the day to day storage management from the global zone OmniOS/napp-it. I don't update OmniOS very often, but to minimise nested Zone/VM management, perhaps I could setup a script to Clone a Zone OmniOS VM template, configure settings for each, add datasets etc. Once setup, I hoped I wouldn't need to access the Zones often.
I hoped there would be minimal impact on memory & cpu from sharing datasets through zones.
It looks like I can do most of the day to day storage management from the global zone OmniOS/napp-it. I don't update OmniOS very often, but to minimise nested Zone/VM management, perhaps I could setup a script to Clone a Zone OmniOS VM template, configure settings for each, add datasets etc. Once setup, I hoped I wouldn't need to access the Zones often.