Samba is discoverable by Windows but not discoverable by another Linux machine
ypj0202 opened this issue · comments
As mentioned in the title, it is discoverable and accessible by other Windows machine with wsdd enabled. However, other Linux machine is not cannot discover it (But can access via IP) even avahi service is running on the host with no errors.
Host: Raspberry Pi 4
OS: Debian 11
Used version: a3.18.0-s4.18.2-r0
Network mode: Host
can you check if your avahi configuration is exposing the samba server?
it might be a problem if the host also runs an avahi server - please mount the configuration folder of avahi so that the container can add it's avahi samba config. avahi server restart is required after the config was placed.
also you can check with an avahi/zeroconf explorer tool (there are tools and even apps available which can show everything which is exposed within your network)
also make sure, that avahi only works within one network and is not routed!
hope those hint's help you
Thanks for you quick response. I have tried before to mount host's avahi folder to the container. However, only windows is able to discover. I have tested discovery on Ubuntu, it did not work but I can connect to samba share folder by entering the IP address.
UPDATE
I have tested on my android phone running Android 13, scanned the entire network, no samba server found.
My configuration is as follows:
services:
samba:
container_name: Samba-Server
image: test-build/samba:a3.18.0-s4.18.2-r0
restart: always
network_mode: host
cap_add:
- CAP_NET_ADMIN
environment:
SAMBA_GLOBAL_CONFIG_netbios_SPACE_name: Samba
SAMBA_GLOBAL_CONFIG_client_SPACE_max_SPACE_protocol: SMB2
SAMBA_GLOBAL_CONFIG_client_SPACE_min_SPACE_protocol: NT1
SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol: NT1
SAMBA_GLOBAL_CONFIG_server_SPACE_max_SPACE_protocol: SMB2
SAMBA_CONF_LOG_LEVEL: 3
SAMBA_GLOBAL_CONFIG_wins_SPACE_support : 'yes'
SAMBA_GLOBAL_CONFIG_follow_SPACE_symlinks : 'yes'
# uncomment to disable optional services
#WSDD2_DISABLE: 1
#AVAHI_DISABLE: 1 # Have tried to uncomment this line
GROUP_user1: 1500
ACCOUNT_user1: password
UID_user1: 1000
GROUPS_user1: user
SAMBA_CONF_SERVER_ROLE: standalone server
SAMBA_CONF_WORKGROUP: WORKGROUP
SAMBA_CONF_SERVER_STRING: Samba-Server
SAMBA_CONF_MAP_TO_GUEST: Bad User
SAMBA_VOLUME_CONFIG_user1: "[User1]; path=/shares/user1/; valid users = user1; create mask = 0777; directory mask = 0777; guest ok = no; read only = no; browseable = yes"
volumes:
- /etc/avahi/services/:/external/avahi
# avoid loops when mounting folders to /shares (I'd recommend explicit mapping for each share)
- /mnt/sda1/share/user1:/shares/user1
Same here; I can't discover my RPI4B from an Xbox container from Kodi.
EDIT: I have a Windows host that can discover the Samba share. And when I share a folder with the Windows host, Xbox Kodi can discover it.
It works if the URL is written manually.
I used almost his config and same problem
Note : There is errors in logs :
[2023/08/09 12:19:29.191739, 2] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log)
tdb(/var/lib/samba/registry.tdb): tdb_open_ex: could not open file /var/lib/samba/registry.tdb: No such file or directory
[2023/08/09 12:19:29.191857, 3] ../../lib/dbwrap/dbwrap_tdb.c:484(db_open_tdb)
Could not open tdb: No such file or directory
[2023/08/09 12:19:29.243721, 3] ../../source3/auth/token_util.c:688(finalize_local_nt_token)
Failed to fetch domain sid for WORKGROUP
Same with me. It worked in past, but i was changing hw and OS and now it is not working. (previously i had samba installation also in OS, not sure if that can be related) Manual url works.
what OS are you using now? do you start with host avahi or container avahi?
I've made some updates, previously avahi wasn't configured when there was no timemachine share available - this should be now resolved. It might have a positive impact on this issue as well
Issue seems to be still present,
tested on arm64: latest@sha256:6a9edb840077707afaab565a7b919cd20eee857f985b2d94c33cb589d54b8c17
I got a new pull request which added nmbd I ignored it cause I thougt it's a compatibility layer which only legacy systems relay on.
but it seems like it helped the guy who did the pull request with similar issues, as you're facing!
Issue Solved with sha256:0f8e795f96940e61eeeaa9feea7ec21c8ecb7d12bd0f6ce7701ca1c3e762d71d !
Thank you very much!
I'll close this issue than - makes sense that the missing nmbd was the root of this problem - can't believe I didn't think about that 😄 sometime you miss the most obvious things 🤦
@jfhenriques thanks for taking the time of looking into this container and fixing this issue!