I use TrueNas to share data to one or more usergroups (vlans). As example a share for sharing data with my family and an other share with guests.
However, where I can limit access for iSCSI to a certain IP-range (I would prefer vlan), I can not do that for SMB !
I can not solve that via the fire wall as well since If I allow my guest to reach SMB in the TrueNas VLAN I give them access to all SMB’s, which is not exactly what I had in mind.
I can of parly solve this by creating a VM belonging to a certain vlan, but that is nasty.
It’s available for Legacy Shares only (shares that were using No Preset before upgrading to 25.10). Hosts Allow and Deny will both be generally available again in 25.10.2.
I’d say you’re coming at this from the wrong angle. VLANs are for segregating traffic as it transits your network fabric, not for controlling access to services on a server.
From an OSI point of view, VLANs are layer 2, which your SMB server (which operates on layers 6 and 7) knows nothing about. You can choose to use different IP ranges on your VLANs, and firewall off your SMB service at layer 3, based on IP address, but you don’t get any granular file/directory/share control with that method.
As others have pointed out, the system is designed to work on user logins and permissions. I would recommend making the SMB service available to all on your network, and control access with permissions. Use the right tools for the job
That I allow everybody in the vlan guests for instance access to the SMB without account. Of course I could give them a dummy account … but I do not like that and people in another vlan could use that dummy account as well.
So I really prefer to use the account option only as a second layer for data which needs more protection
@louis, you talk about not liking things that are insecure, but having open SMB shares with no username/password to access them, or shared credentials, is terrible practice, imho.
The management GUI does not need to be on the same network (again, VLANs have got nothing to do with this, stop conflating the two) as the data your clients access. You can have multiple physical NICs on different networks and bind the SMB (or any other service) to different NICs, or you can create a bridge interface and create a load of virtual NICs on different VLANs. But again, this isn’t the best way to secure file shares.
If things are ‘using the same route’, that’s not asymmetric routing. And VLANs have nothing to do with routing. VLANs are layer 2, ethernet, seperate from TCP/IP and routing.
Binding a share to a certain NIC or better a VLAN as related to a nic would be wonderfull, it is exactly what I want. However I really have no idea how to do that !
Note I discovered that the SMB-service can be bind to a certain address. But I do not know the impact and that is for the whole service not for a particular share … Is that where you are referring to?
Asymmetric routing is IHMO that the answer is not send back via the same network path than it arrived. And since there is only one default gateway every thing is routed via the NIC or vlan to which the default gateway belongs. Which is not OK and also not the way I accept in my network.
Rather deploy individual SMB instances e.g. in LXC containers bound to individual VLANs. TrueNAS has a single Samba instance sharing the IP stack with the UI and all other services running on the NAS. The only way to true separation is LXC or VMs.
It’s probably better not to have multiple samba instances export the same data. It would be impossible to have them properly coordinate SMB protocol semantics on the underlying files.
Louis, I’m not going to tell you you’re doing this wrong, because there is no right and wrong. The wonderful thing about FOSS is that you’re free to do whatever you want with the tools you’re given.
But what you’re not doing is using these tools in the way the designers, programmers, maintainers and the vast majority of users intended and expect them to be used.
You can continue to try and implement things the way you want, but you’re unlikely to find a solution, or anyone that’s able to help you support it, due to the non-standard way you’re trying to set it up. My suggestion would be to listen to the advice of the community members here and change your plan.
Another nasty solution that works is running a small SBC with a 2.5" disk just for your guests. I do that with Sonos here since there i no way I’m going to allow SMB1 / NTLMv1 access to my NAS. I suppose I could run a VM with dumbed-down security profile but usually those Pi file servers last about 3 years before they manage to corrupt themselves and then it’s time for another OS transition anyway.
