I can’t reliably create the issue on local clients (LAN)
But it’s almost 100% reliable on remote clients,  I’ll schedule a time with one 
of remote people and setup a remote desktop session.


Brock Palen
[email protected]
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting



> On Feb 6, 2026, at 2:45 AM, Sebastian Sura <[email protected]> wrote:
> 
> Do the clients show up when you do `status dir` ?
> 
> *status dir
> ...
> Client Initiated Connections (waiting for jobs):
> Connect time        Protocol            Authenticated  Name
> ====================================================================================================
> 06-Feb-26 08:40     54                  1  client-initiated-fd
> ====
> 
> If they do, you could try finding out what bareos thinks by starting the 
> client with debugging enabled, i.e.
> 
> bareos-fd -f -d1000
> 
> and see what it spits out when you try connecting via the director.  If the 
> connection does _not_ show up,
> you can still do the same and check what the filed says when _it_ tries to 
> connect.
> Similarly you can do
> *setdebug dir trace=1 level=1000
> To see what the director reports during the connection attempt. Let me know 
> if something interesting showed up.
> 
> Kind Regards
> Sebastian Sura
> 
> Am 05.02.26 um 20:57 schrieb 'Brock Palen' via bareos-users:
>> I have tried both clients with jobs already running and ones that don’t and 
>> the hang is reliable.
>> 
>> Up until recently I could check the status of any client initiated 
>> connection without issue.  If this  isn’t a problem for others this is a 
>> head scratcher about my site (other than enabling IPv6 on the WAN address of 
>> the NAT)  what hange might have impacted baroes.
>> 
>> 
>> Brock Palen
>> [email protected]
>> www.mlds-networks.com
>> Websites, Linux, Hosting, Joomla, Consulting
>> 
>> 
>> 
>>> On Feb 4, 2026, at 10:51 AM, Bruno Friedmann (bruno-at-bareos) 
>>> <[email protected]> wrote:
>>> 
>>> Hi Brock,
>>> 
>>> We use that feature all the time here to backup remote worker, and it 
>>> works. But beware only when there's no jobs running, (otherwise it would 
>>> need another connection which doesn't exists).
>>> Would that make sense in your case ?
>>> 
>>> On Thursday, 29 January 2026 at 21:48:39 UTC+1 Brock Palen wrote:
>>> So opening this back up, I don’t think it’s IPv6 related at all.
>>> 
>>> I have disabled ipv6 for the director and storage. I have confirmed they 
>>> are not listening using netstat I also removed the AAAA DNS record for the 
>>> server.
>>> 
>>> Clients using configs like:
>>> Client {
>>> Name = sue-hp-touch-fd
>>> FDport = 9102
>>> Address = 192.168.10.6
>>> #Address = 192.168.67.21
>>> Catalog = myth_catalog
>>> Password = “<snip>"
>>> Connection From Client To Director = yes
>>> Heartbeat Interval = 60
>>> }
>>> 
>>> 
>>> 
>>> setdebug level=1000 trace=1 dir
>>> 
>>> I’m getting errors like:
>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
>>> want-read
>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
>>> want-read
>>> myth-dir (500): lib/crypto_openssl.cc:1544-0 SSL_get_error() returned 
>>> want-read
>>> myth-dir (800): dird/job.cc:732-0 JobMonitorWatchdog 0x565b9f0369e0 called
>>> 
>>> When I do
>>> 
>>> status client=<client>
>>> 
>>> For clients that use client initiated connection. Ironically their jobs 
>>> still run, but status fails and just hangs, and I have to break out of 
>>> bconsole using Ctl+C
>>> 
>>> I have been using this for years I have tried giving the client a valid IP 
>>> on the local network (even though that’s not the hots address) and random 
>>> addreses. Behavior is the same.
>>> 
>>> Machines that don’t use this or are on the same local LAN work fine. It’s 
>>> only the road warriors. It’s more annoying but I don’t htink it’s expected 
>>> behavior.
>>> 
>>> Details:
>>> *status client=sue-hp-touch-fd
>>> Connecting to Client sue-hp-touch-fd at 192.168.10.6:9102
>>> Probing client protocol... (result will be saved until config reload)
>>> Handshake: Immediate TLS, Encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>>> 
>>> <hang>
>>> 
>>> 
>>> 
>>> 
>>> Brock Palen
>>> [email protected]
>>> www.mlds-networks.com
>>> Websites, Linux, Hosting, Joomla, Consulting
>>> 
>>> 
>>> 
>>>> On Jan 5, 2026, at 3:24 AM, Bruno Friedmann (bruno-at-bareos) 
>>>> <[email protected]> wrote:
>>>> 
>>>> Hi, Just for information, I'm using ipv6 since years (>5) here on my 
>>>> network, and I've started 2 years ago to only use ipv6 for the backup, so 
>>>> bareos here is using 100% of the time ipv6.
>>>> So for most of the task it works well, but I don't use the client 
>>>> initiated feature.
>>>> 
>>>> I might give it a try next week-end ...
>>>> 
>>>> On Saturday, 3 January 2026 at 23:29:36 UTC+1 Brock Palen wrote:
>>>> We were modernizing some and rolling out ipv6
>>>> The bareos server always had ipv6 but it was not part of DNS nor allowed 
>>>> through the firewall.
>>>> 
>>>> After adding it to DNS and opening up the firewall clients that connect 
>>>> directly over the wan (not over the VPN or local network) all use client 
>>>> initiated connections.
>>>> 
>>>> They should show up even trigger backups but if you do:
>>>> 
>>>> status client=<client>
>>>> 
>>>> A large fraction would fail and drop the connection and come back later.
>>>> 
>>>> Telling bareos director to only listen on ipv4 things started working 
>>>> again.
>>>> 
>>>> I’m guessing I have created some sort of resolution/routing loop, and were 
>>>> actaully ok with ipv4 just more curious as rolling out ipv6 for our mail 
>>>> and everything else has been a learning experience.
>>>> 
>>>> 
>>>> Brock Palen
>>>> [email protected]
>>>> www.mlds-networks.com
>>>> Websites, Linux, Hosting, Joomla, Consulting
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "bareos-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to [email protected].
>>>> To view this discussion visit 
>>>> https://groups.google.com/d/msgid/bareos-users/f45c79ae-c09e-477d-983f-525fad705cb9n%40googlegroups.com.
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "bareos-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to [email protected].
>>> To view this discussion visit 
>>> https://groups.google.com/d/msgid/bareos-users/ddb950cf-fab8-4bba-8bd8-7becd4bac142n%40googlegroups.com.
> 
> -- 
> Sebastian Sura                  [email protected]
> Bareos GmbH & Co. KG            Phone: +49 221 630693-0
> https://www.bareos.com
> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
> Komplementär: Bareos Verwaltungs-GmbH
> Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion visit 
> https://groups.google.com/d/msgid/bareos-users/63e00a08-53a1-4062-932e-ee0b138596ad%40bareos.com.

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/bareos-users/AA3F7360-EE1A-4DD4-B50F-68080C53096D%40mlds-networks.com.

Reply via email to