Cu 163, 164, 165_RC : backup restore : DynDns entry missing

The latest referene was “right now” - c.f. the date/time :

Re-done again:
…/2022-03-24_12-17__cu-165-Testing/var/ipfire : NO ./ddns/ subdirectory contained.

according to " System → Home", the version installed is:
. . . IPFire 2.27 (x86_64) - Core Update 165 Development Build: master/38f5bc99

Via ssh:

ll /var/ipfire//.conf | grep ddns
-rw-r–r-- 1 nobody nobody 101 Mar 24 11:14 /var/ipfire/ddns/ddns.conf

ll /var/ipfire/*/config | grep ddns
-rw-r–r-- 1 nobody nobody 49 Mar 22 16:35 /var/ipfire/ddns/config

ll /var/ipfire/*/settings | grep ddns
-rw-r–r-- 1 nobody nobody 0 Feb 9 2018 /var/ipfire/ddns/settings

I have just done a backup on my CU164 running system and I found that a whole bunch of directories were not backed up.
I was missing

  • captive
  • connscheduler
  • ddns
  • dhcp
  • dhcpc
  • dma

However this can’t be directly related to the change to CU 164 as I carried that out on 14th March and I have a backup, that I run weekly from a script, which is dated 19th March and that has all the directories backed up.
Also the backup run by the CU164 change on the 14th also has all the directories.
Ones I am running today either from the WUI or using my script all have the above directories missing.
Actually I must check the whole list to see fi there are any others missing that would have been there in the past.
Don’t understand what is happening at the moment.

I have posted other problems which - in light of your findings - might be related; e.g.


During near future, I will definitely take a leaf out of my own book
and not miss out exploiting CloneZilla:


Good luck, kind regards!

Additionally the following are also missing

  • accounting addon
  • dnsforward
  • extrahd
  • isdn
  • logging
  • mac
  • main
  • modem
  • optionsfw
  • pakfire
  • qos
  • remote
  • sensors
  • wakeonlan
  • wio addon
  • wireless

So there are a huge number missing from my backup.

Can you check your backup and see if the ones I have listed are also missing in your ipfire directory. This would show if the directories not being backed up are consistent for the two of us. Makes the fault easier to diagnose.

I may raise a bug for this but will first check out some of what you highlighted. My script was using directly not backupctrl and the issue with backupctrl was a problem with the paths. I will have a look at that. Although what I don’t understand is why the backups were okay up to 19th March which is after I had updated to CU164

1 Like

Please, c.f. PM:
. . . ls -h -AlgR 2022-03-24_12-17__cu-165-Testing
. . . 2022-03-24_12-17__cu-165-Testing.txt.gz


Feel free to request for more :slight_smile:

I think you were right about the backupctrl issue being related.

I think it was caused by a change issued in CU164 which changed the backup include and exclude files to have their entries as relative paths and not absolute paths. I think that may have then caused the backupctrl issue.

Either way, changing the include file paths back to absolute (ie prepending a / at the start of every line) has made my backup now include all the required directories.

I will have a look at testing out the path change that @Michael implemented to fix the backupctrl issue to confirm if that also fixes this problem - ie they are driven by the same root cause. However I will over to my vm testbed for that because I will have to copy in the modified backupctrl file from the git repository and the path change was made to one of the c files for backupctrl.

Anyway a simple temp fix for your running system is to add a / at the start of each line in


The fix for the backupctrl issue is in next which means it will be seen in CU166

1 Like

I fear there are more $PATH-related issues - e.g.:

Adding aliases into .bashrc like

cat .bashrc

[[ -f ~/.bash_aliases ]] && . ~/.bash_aliases

yields the following failure at ssh-login:

. . . Last login: Thu Mar 24 13:25:43 2022 from
-bash: /root/.bash_aliases: Permission denied

Directly afterwards, commanding
. . . source ~/.bash_aliases
works instantaneously …


…/2022-03-24_13-37__cu-165-Testing____slash $ ll var/ipfire/ddns/

-rw-r–r-- 1 manfred manfred 49 22. Mär 16:35 config
-rw-r–r-- 1 manfred manfred 101 24. Mär 11:14 ddns.conf
-rw-r–r-- 1 manfred manfred 0 9. Feb 2018 settings

So I just ran CU166 (next) which has the backupctrl path fix and the fix looks to work in that the previous issue did not occur but there was another failure but that is due to an uninitialised variable in something that is still being worked on.

However, key thing is that with the backupctrl path fix in place the missing directories in the backup were still missing so it looks like this is a different bug so I will raise it in the IPFire Bugzilla.

1 Like

If backupctrl call ( a bash script ) the problem is the missing expansion of entries like ‘var/ipfire//.conf’.

Except that I had the same problem if I ran directly from the command line. The directories were still missing.

bug raised

1 Like

@Adolf , I had submitted bug 12816 earlier which I think may be related.

Hi Rejjy,
Yes I only saw it after I had submitted mine.

Reading through it i think it is the same.

This one may be related…

The fix for that backupctrl issue is in next (CU166) and I installed it onto a vm on my vm testbed and it did not fix this problem of the missing directories in the backup. It may still be related to paths because of the change from absolute to relative paths in the include file but the paths change in suid.c for backupctrl is not enough on its own.

1 Like

I’ve added a comment ( and solution ) about this to bug #12817

Just a reminder:
This has to be re-edited with every “Testing” updates

1 Like

Core Update 165 Development Build: master/c55f5c8e: still the same.