TrueNAS 12-RELEASE not seen by Mac OS

MikeyG

Patron
Joined
Dec 8, 2017
Messages
442
Was a fix for this ever found? I have Truenas 12 U8 and Time Machine shares disappear after a while. I only use it every few weeks, so I can't tell how long they stay up for. If I restart the SMB service they show up again and backups run ok.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Was a fix for this ever found? I have Truenas 12 U8 and Time Machine shares disappear after a while. I only use it every few weeks, so I can't tell how long they stay up for. If I restart the SMB service they show up again and backups run ok.

These sorts of things have quite a lot to do with network configuration, switch, and other devices in the environment. Some vendors power through by basically restarting mDNS every 60 seconds or less. But in my own home lab, our labs, and customer sites this isn't really a thing. You can try debugging avahi (what we're using for mDNS) or perform careful packet capture / analysis. If you restart jails / plugins through iocage commands this can also potentially break mDNS (we restart mDNS service in this case automatically if done through webui / api).
 

MikeyG

Patron
Joined
Dec 8, 2017
Messages
442
Thanks for responding. Anything in particular I can watch out for? I don't think I have a very complicated setup as it's a home lab. Flat network with a couple of switches. A couple of LAGGs set up on TrueNAS. Could this be caused by devices on the network? I do have a couple of plugins, but I never restart them, and only do so from the GUI. They are fairly basic, (Netdata and speedtest).

I don't want to make you run through a whole troubleshooting process, but if there are any guides I could take a look. I did try running avahi in debug mode using avahi-daemon --debug, but nothing really popped out at me as erroneous. If it comes down to packet captures, I probably won't spend the time on it for something like this though.

Worst case, if I schedule midclt call service.restart mdns to be run once in a while, might that fix it?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Thanks for responding. Anything in particular I can watch out for? I don't think I have a very complicated setup as it's a home lab. Flat network with a couple of switches. A couple of LAGGs set up on TrueNAS. Could this be caused by devices on the network? I do have a couple of plugins, but I never restart them, and only do so from the GUI. They are fairly basic, (Netdata and speedtest).

I don't want to make you run through a whole troubleshooting process, but if there are any guides I could take a look. I did try running avahi in debug mode using avahi-daemon --debug, but nothing really popped out at me as erroneous. If it comes down to packet captures, I probably won't spend the time on it for something like this though.

Worst case, if I schedule midclt call service.restart mdns to be run once in a while, might that fix it?

Other devices on the network can impact mDNS. There is some discussion of issue in avahi mailing lists and in github. For that matter, you can try hard-coding our avahi configuration to only bind to one of your interfaces. Clients may invalidate an mDNS record if there is an observed failure to resolve, and so improper igmp settings can basically cause mDNS to get deregistered for a network (c.f. RFC6762 Section 10.5 - Passive Observation of Failures (POOF)). A lot of home networking equipment (even more expensive stuff like ubiquiti) can have defaults that tend to break mDNS (this is also covered on their forums) under the guise of reducing unnecessary traffic to wireless clients and such things. You can maybe try to correlate the breakdown of mDNS registration with other events on network. Try only binding avahi (manually editing the config file) to a single interface on which it must be located. Disable wireless entirely on MacOS and only use wired connection, etc, etc.

A consequence of RFC6762 secition 10.5 is that if an overly intelligent network device garbling mDNS messages can cause a normally working device to flush its mDNS cache and no longer know where we are.
 
Last edited:
Top