Can't see shares from Windows 10

[bonny1992]

Here's my command:

docker run --name samba -it -d \
	-p 139:139 -p 445:445 \
	-p 137:137/udp -p 138:138/udp \
	-e USERID=1000 -e GROUPID=1000 \
	-v /media/elements:/mount \
	-v /home/rock64/docker/samba/add.conf:/add.conf \
	--restart unless-stopped \
dperson/samba:aarch64 \
	-p -n \
	-s "public;/mount;yes;no;yes" \
	-w "WORKGROUP" \
	-I "/add.conf"

and this way I cannot access any share on my Windows 10 PC unless I docker exec -it samba /bin/sh and I type smbd in the new console.

Any help?

[Shenanigans77]

I'm having a similar issue.

[LeoRX]

From memory its Windows 10 disabled annoymous share by default. have a look here.

https://support.microsoft.com/en-au/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser

[neben]

I had the same issue. Turns out this was just the -p option setting the permissions on my share. This can take a long time, as it's recursively changing ownership on every file in the share, and this happens when the docker container is started. The smbd daemon is started only after this finishes. You can check if this is the case by inspecting the tasks running in the container; if it includes something like chown -Rh smbuser /mount then this is the issue.

If your share has the correct permissions, just remove the -p option. Otherwise, you'll either have to set them manually or keep using the -p option and wait until it finishes each time you restart the container.

[dperson]

@bonny1992 what is in the docker logs samba? It shouldn't really like having you run smbd again, and I can't picture how that helps things. It could just be a delay in setting the permissions as @neben mentioned. I can have that run in the background and let samba start up...

[bonny1992]

Sincerely I don't know why running it again make it works normally.

The only things that appears in the logs are those two lines:

Global parameter disable netbios found in service section!
usermod: no changes

The first one is a fix I tried for not seeing the shares on W10, the second I don't know.

But yeah, now that I know that I just have to wait or remove the -p option I won't start smbd again. (I feel that now it's faster because it already changed all the permissions it needed).

[neben]

Sincerely I don't know why running it again make it works normally.

In reality that's most likely because it hadn't been started in the first place (because the startup script was still changing permissions and hadn't reached the point where it starts smbd). So you starting it manually was in reality the first time the daemon was started (in the lifespan of that container).

[bonny1992]

Thank you for your explaination @neben but shouldn't it throw some kind of errors during the file handling?

[neben]

shouldn't it throw some kind of errors during the file handling?

Not if there are none, I guess. In my case it was just a big old drive with lots of files on a weak Raspberry Pi — chowning that can take some time, probably even worse if it's an NTFS drive.