Make linux samba share visible in windows with subnets

I have been trying for a while now to get samba share discovery working across subnets, but I can't figure out what is wrong in my config.

For my samba share I use the linux fileserver turnkey image. I use wsdd to make the samba share visible. The configuration I have works right now, if the fileserver and my windows client are in the same network. When I move the fileserver into its own network, it's not visible anymore, yet reachable by directly entering the IP in the file explorer.

  • Windows Client IP: 192.168.1.50 (192.168.1.0/24, gateway: 192.168.1.254)
  • SMB Share IP: 192.168.0.109 (192.168.0.0/24, gateway: 192.168.0.254)

There is no firewall on the fileserver enabled. The router (OpenWRT) is configured to accept Input, Output and Forward from and to the two subnets. I have not added any port forwards or traffic rules.

The wsdd config looks like this:

WSDD_PARAMS="-v --workgroup='WORKGROUP'"

(I only pasted the relevant entries from the config files - hope I didn't miss anything)

network

~# cat /etc/config/network
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.254'

config interface 'iot'
        option proto 'static'
        option device '@lan'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'
        option type 'bridge'

firewall

~#cat /etc/config/firewall
config zone
        option name 'iot'
        option input 'ACCEPT'
        option output 'ACCEPT'
        list network 'iot'
        option forward 'ACCEPT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config rule
        option src_ip '192.168.1.0/24'
        option dest_ip '192.168.0.0/24'
        option name 'Allow broadcast from Windows subnet to Samba subnet'
        option target 'ACCEPT'
        option proto 'udp'
        option dest_port '137-138'
        option enabled '0'

config rule
        option src_ip '192.168.0.0/24'
        option dest_ip '192.168.1.0/24'
        option name 'Allow broadcast from Samba subnet to Windows subnet'
        option target 'ACCEPT'
        option proto 'udp'
        option dest_port '137-138'
        option enabled '0'

config forwarding
        option src 'iot'
        option dest 'lan'
config forwarding
        option src 'lan'
        option dest 'iot'

umdns

~# cat /etc/config/umdns
config umdns
        option jail 1
        list network lan
        list network iot

I found several threads using smcroute, but I don't have 2 physical devices?

ubus call umdns browse does not list my samba share, but other devices from the 192.168.0.0/24 subnet.

hi,

to me this seems incorrect

@ notation is an additional interface on the an existing object, i dont believe option type bridge is correct. also usually traffic between one zone to another can be enabled via zone forwarding and not via the zone input/output/forwarding form. maybe you can give a try (like using lan to wan as example).

1 Like

option type 'bridge' must be from an earlier experimentation, I don't think it did anything. Anyway, I removed it.

This is what it looks like it LuCI
image

And my firewall config

Does this look correct?

just a note: zone A to zone B is unidirectional, i.e. zone A can initiate traffic into zone B (and get reply), but zone B cannot initiate traffic into zone A.
so if iot network is untrusted (i guess otherwise you'd just use lan zone) maybe just allow lan->iot and. and maybe you'll need firewall rule to allow specific traffic from iot clients accessing lan servers.

Yes I know :slight_smile: . I just did this so I can exclude the firewall from interfering with what I want to accomplish.

In case it's important, here is the smb.conf

~# cat /etc/samba/smb.conf
#======================= Global Settings =======================
[global]
workgroup = WORKGROUP
server string = %h server
log level = 0
log file = /var/log/samba/log.%m
max log size = 50

guest account = nobody
unix extensions = yes
map to guest = Bad User

time server = no
wins support = no
disable netbios = yes
multicast dns register = yes

remote announce = 192.168.1.255/WORKGROUP

# Special configuration for Apple's Time Machine
fruit:aapl = yes
#======================= Share Definitions =======================
[Scan]
        hide dot files = yes
        browseable = yes
        writeable = yes
        public = yes
        path = /mnt/data/Scan
        write list = printer,@services
        force create mode = 755
        force directory mode = 755
        printable = no
        follow symlinks = yes
        guest ok = yes
        guest only = no

actually i have a very similar setup, i have lan to guest zone forwarding and one rule

config rule
        option name 'Allow SMB from guest to Samba server'
        option src 'guest'
        option dest 'lan'
        list dest_ip '192.168.1.201'
        option target 'ACCEPT'
        list proto 'tcp'
        list proto 'udp'
        option dest_port '139 445'

and seems doing the job

I have no experience with umDNs but did this some time ago with Avahi.

I think for mDNS reflection you have to allow UDP port 5353. see:

Can you see the samba share in a windows Explorer > Network though? Access works, as I can access the samba share via IP directly. It's just the discovery that doesn't work.

@egc I have added the firewall rule already:

config rule
        option src_port '5353'
        option src '*'
        option name 'Allow-mDNS'
        option target 'ACCEPT'
        option dest_ip '224.0.0.251'
        option dest_port '5353'
        option proto 'udp'

Running wsdd in verbose mode I can see that probes from my windows client 192.168.1.50 are picked up:

~# journalctl --follow -u wsdd.service
-- Journal begins at Tue 2023-04-25 11:32:24 UTC. --
Apr 26 14:37:06 smb wsdd[2809]: 2023-04-26 14:37:06,317:wsdd INFO(pid 2809): Done.
Apr 26 14:37:06 smb systemd[1]: wsdd.service: Succeeded.
Apr 26 14:37:06 smb systemd[1]: Stopped Web Services Dynamic Discovery host daemon.
Apr 26 14:37:06 smb systemd[1]: Started Web Services Dynamic Discovery host daemon.
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,504:wsdd WARNING(pid 2833): no interface given, using all interfaces
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,506:wsdd INFO(pid 2833): using pre-defined UUID cd0ed126-b7d2-5ee5-9cee-39bfba91dda9
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,508:wsdd INFO(pid 2833): joined multicast group ('239.255.255.250', 3702) on 192.168.0.109%eth0
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,508:wsdd INFO(pid 2833): scheduling Hello message via eth0 to ('239.255.255.250', 3702)
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,512:wsdd INFO(pid 2833): joined multicast group ('ff02::c', 3702, 22364, 2) on fe80::b806:5bff:fefc:a17%eth0
Apr 26 14:37:06 smb wsdd[2833]: 2023-04-26 14:37:06,513:wsdd INFO(pid 2833): scheduling Hello message via eth0 to ('ff02::c', 3702, 22364, 2)
Apr 26 14:37:11 smb wsdd[2833]: 2023-04-26 14:37:11,085:wsdd INFO(pid 2833): 192.168.1.50:60693(eth0) - - "Probe urn:uuid:29b18394-16f9-4343-821c-4476d9d19012 UDP" - -
Apr 26 14:38:33 smb wsdd[2833]: 2023-04-26 14:38:33,605:wsdd INFO(pid 2833): 192.168.1.50:51945(eth0) - - "Probe urn:uuid:f47968db-9386-4cdc-a632-e1afc2a4eba6 UDP" - -
Apr 26 14:39:24 smb wsdd[2833]: 2023-04-26 14:39:24,933:wsdd INFO(pid 2833): 192.168.1.50:49228(eth0) - - "Probe urn:uuid:f08390de-dc4a-4323-b8c3-07b4ed1eafc9 UDP" - -

wsdd only works on the same subnet.

The advertising between subnets is done with umDNS so you should research that.
Unfortunately I have no experience with umDNS

1 Like

no, network discovery is not working.

but according to man smb.conf this can be used

remote announce = 192.168.2.255/SERVERS 192.168.4.255/STAFF
the above line would cause nmbd to announce itself to the two given IP addresses using the given workgroup names.

so in your case this might help

remote announce = 192.168.1.255/WORKGROUP  192.168.0.255/WORKGROUP

if not, you'll need mDNS.

why cannot use \\ip\share format, you said it is actually working?

I wanted to make it easier on some devices to find the share, e.g. on a printer to scan to the share. I'll look into remote announce and mdns, thanks!