Can't connect to shared drive when not using host networking mode

[shred86]

Describe the bug Edit: Actually seeing this issue with the host networking option enabled as well...

When attempting to use this without the --net=host option and just forwarding all the ports specified in the read me,, I'm unable to connect to the samba drive. Using Mac OS finder Go > Connect to server, I type in the address of my server running this container smb://172.16.16.1 and after clicking connect, I receive:

There was a problem connecting to the server “172.16.16.1”.

Check the server name or IP address, and then try again. If you continue to have problems, contact your system administrator.

To Reproduce Steps to reproduce the behavior:

1. Disable the host networking option and forward all ports specified in the read me.
2. Attempt to connect to the samba drive.

Expected behavior Should be able to connect to the shared drive.

How you're launching your container

Using docker-compose:

  samba:
    image: mbentley/timemachine:smb
    container_name: samba
    restart: unless-stopped
    environment:
      - PASSWORD=redacted
      - SHARE_NAME="Backup"
    volumes:
      - /home/username/backup:/opt/timemachine
      - timemachine-var-lib-samba:/var/lib/samba
      - timemachine-var-cache-samba:/var/cache/samba
      - timemachine-run-samba:/run/samba
    ports:
      - 137:137/udp
      - 138:138/udp
      - 139:139
      - 445:445

Container Logs

Every time I attempt to connect, I see this in the container logs:

Failed to fetch record!
pcap cache not loaded

Additional context

[shred86]

So after randomly trying various things, it appears if I attempt to specify the SHARE_NAME, I can't connect to the drive from my computer. If I let it use the default of TimeMachine, it works fine. I even tried using SHARE_NAME with a different name than before, but same issue. I'm not sure if something changed in the latest image but this seems to be the issue for me. Would be curious to know if anyone else out there is running the latest image of this container (released about 10 hours ago) with SHARE_NAME set to something other than the default.

[mbentley]

First of all, is 172.16.16.1 the container's bridge IP address when not using --net=host or is 172.16.16.x the subnet you're using for your physical network? Just making sure as you would need to use the host's IP address where the container is running on if you're mapping the ports as that's not a typical IP range used for most home setups (assuming this is a home setup).

The Failed to fetch record! and pcap cache not loaded messages are normal. I did a quick scan of the entrypoint to see if there is a chance that I've missed a TimeMachine default hard coded value and I did not see one.

Did you check out the https://github.com/mbentley/docker-timemachine#conflicts-with-samba-andor-avahi-on-the-host section to see if any of that applies to your environment on your host? Just want to narrow down to see if there is a conflict on the host or not.

[shred86]

172.16.16.1 is the IP address of the host machine. My home network is a 17.16.16.X/24 subnet (I use Sophos XG for my firewall/router and that’s just what it defaults too, so I’ve just stuck with it).

I did review that section. The weird part is it was working fine for about 2 years. It was when I tried to stop using the host networking mode that I ran into this issue. When I tried going back to host networking, the issue remained. It wasn’t until I removed the SHARE_NAME setting that everything started working (both with and without host networking).

I did recently enable a second NIC on my host machine, so I’m guessing that might be a contributing factor. The weird part is I was able to see the shared drive. When I attempted to connect to it, I would get a prompt for a username/password. It’s just when I tried submitting the username/password I would receive that error mentioned above. I’m just not sure why removing SHARE_NAME resolved it.

[mbentley]

Hmm, this might be a long shot but if you have multiple interfaces, I am wondering if there is a problem with the interface that it's choosing to bind to. I was just able to use port mapping, switch to net=host, and then back on a brand new VM and I was able to connect without issue. One thing that might be worth trying is that when you're mapping ports on the host, maybe try to specify the IP in your compose file along with the ports. I think this is the right syntax:

...
    ports:
      - "172.16.16.1:137:137/udp"
      - "172.16.16.1:138:138/udp"
      - "172.16.16.1:139:139"
      - "172.16.16.1:445:445"

I didn't have docker-compose on my test machine so I was only testing with docker run... commands so I didn't test the syntax but from the docs, it looks right.

Otherwise, could you try just running a one off container with new temporarily volumes and seeing if it works:

docker run -it --rm \
  --name smbtest \
  -e SHARE_NAME="foo" \
  -e PASSWORD="docker123" \ 
  -v smbtest-opt-timemachine:/opt/timemachine \
  -v smbtest-var-lib-samba:/var/lib/samba \
  -v smbtest-var-cache-samba:/var/cache/samba \
  -v smbtest-run-samba:/run/samba \
  -p 137:137/udp \
  -p 138:138/udp \
  -p 139:139 \
  -p 445:445 \
  mbentley/timemachine:smb

The above here worked for me to connect manually using smb://<ip> in both port mapping and --net=host.

[shred86]

Yeah, that's how I have my docker-compose setup. It was actually to restrict my containers to only one network interface (didn't want them exposed on the other network interface).

When I ran the one off container example you provided, I was able to connect to it just fine. I then went back and tried my setup again with SHARE_NAME="Backup", which is how I had it before, and I run into the same issue.

When I remove SHARE_NAME, it works fine.

This is a head scratcher for sure... good news is it works without SHARE_NAME, so I'm happy to just use it like this. At this point I'm just more curious as to what's causing this issue for me. Might be one of those things I'll never figure out, lol. Appreciate the help with trying to troubleshoot this though.

[mbentley]

OK, so I can reproduce this with compose. Remove the quotes around Backup and it works fine. When quotes are used, it includes the literal quotes in the variable:

No quotes:

$ docker inspect samba | grep Backup
                "SHARE_NAME=Backup",

With quotes:

$ docker inspect samba | grep Backup
                "SHARE_NAME=\"Backup\"",

So then with quotes, it generates a smb.conf that looks like this:

...
["Backup"]
   path = /opt/timemachine
   inherit permissions = no
   read only = no
   valid users = timemachine
   vfs objects = acl_xattr fruit streams_xattr
   fruit:time machine = yes
   fruit:time machine max size = 0

[shred86]

Ah, that was definitely it! That's odd, I've been using it with quotes for over a year. I'm guessing something must have changed on the docker-compose side. Appreciate the help!