Hi,
are there commonalities with this issue?
Best, zargano
IMHO yes. It looks like pretty much the same failure mechanism: Incorrect permissions.
However, I could upgrade from core 156 to core 157 without problems.
Above problems appeared when upgrading from core 157 to core 158.
The IPFire experts need to judge whether there are and what are the commonalities.
1 Like
I am not sure. At least /usr/lib/libgcc_s.so.1 have 0644 permission both on a working as well as faulty IPFire here. I have also checked various other permissions, and I did not spot an 0700 permissions.
In all my cases, the permission 0700 was set wrongly for directories, see above. Files were not affected.
See After reading all those threads about problems with wrong file/folder permissions, I wonder if I should upgrade from 156 to 158?
Do those reported issues apply to all upgrades for version 158 or will I hit the same problems already when pakfire is upgrading to 157?
Or is it merely an issue with the jump from core 157 to 158?
Right now, Iām clueless and uncertain whether to upgrade or not.
1 Like
I upgraded my test box from 156 to 157 and did not have the permission issues mentioned above (or any other issues).
Jun 21 11:26:49 ipfireC157 pakfire: CORE UPGR: Upgrading from release 156 to 157
And I just upgraded the same test machine from 157 to 158. And I did not have any permission issues.
Jul 20 13:53:58 ipfireC158 pakfire: CORE UPGR: Upgrading from release 157 to 158
This is my test machine:
So all was good with the test box!
I also upgraded my production box from 156 to 157. No issues. I havenāt done the 158 upgrade yet (too many people using the internet now)
If you are worried about an upgrade, just make a backup and copy it to your favorite computer. It should be easy to restore if all goes bad!
1 Like
Thanks for your feedback and heads-up!
I always run a backup prior to updating, however, Iām using some custom settings like firewall.local (was it that name?) and I have many Python scripts for monitoring in place and much more.
All of them probably donāt find their way into any IPFire backup, I guess.
Nevertheless, Iām backing up the whole machine using rsync from a remote server. At least, this should save my custom settings as well.
3 Likes
Hi @hellfire
Add the additional files you want to be modified to
/var/ipfire/backup/include.user
and they will be included into the IPFire backups.
4 Likes
I ran a find command to identify all folders with a permission 700. The result is as follows:
[root@IPFIRE1 /]# find -type d -perm 700
./opt/pakfire/etc/.gnupg
./boot/lost+found
./run/samba/ncalrpc/np
./mnt/harddisk/.recycle
./lost+found
./root/.ssh
./root/.config
./root/.config/procps
./usr/lib/python3.8/site-packages <======== chmod 755 ?
./usr/lib/python3.8/site-packages/samba <======== chmod 755 ?
./usr/lib/python3.8/site-packages/samba/dcerpc <======== chmod 755 ?
./usr/lib/cups/filter <======== chmod 755 ?
./usr/lib/cups/backend <======== chmod 755 ?
./usr/share/ppd/cupsfilters <======== chmod 755 ?
./var/ipfire/ovpn/certs
./var/ipfire/cups/ssl
./var/ipfire/samba/private/msg.sock
./var/lib/sasl
./var/cache/ldconfig
./var/log/samba/cores
./var/log/samba/cores/smbd
./var/log/samba/cores/nmbd
./var/log/samba/cores/winbindd
./var/db/sudo/lectured
Which of these folders require a change of the permission to 755?
BTW my hardware is an APU4D4. Recently at core 156 I did a migration from a 32bit IPFire to a 64bit IPFire architecture. At that time I restored the 32Bit backup to the new 64bit installation of IPFire.
1 Like
Ah! Didnāt know this so far.
I guess the file itself wonāt be overwritten during any update procedure?
No it is not overwritten at all.
There is also an exclude.user file so if you have a directory that you want to backup most but not all files then you can add the directory into the include.user file and the files you donāt want backed up in exclude.user
Saves having to enter multiple filenames or if tge filenames to be backed up change over time.
1 Like
Have also the problems after the upgrade, no GUIā¦ How can a backup be restored neither a GUI nor to reinstall?
Yes, you should always upgrade. This bug is affecting only a very small fraction of people and we have to get to the bottom of it, but the update is generally healthy and does not introduce any other known regressions.
Always perform a backup before upgrading.
4 Likes
I did two upgrades today, the 1st was on a VM under proxmox and went wellā¦ The 2nd was on a HUNSN Firewall hardware:
GUI and OpenVPN doesnt work, Internet connection is still possibleā¦
Hi!
IĀ“ve the Same Problem - Webui does not work and openvpn Clients too.
Openvpn N2N is ok and healthy.
I Use a ZotacBox with an Intel Atom DualCore.
Did anybody more Info for fix the Bug?
Have a nice Day 
This looks like pakfire was running more than once at the same time.
Please run āchmod 755 /libā and that should fix at least something.
Oh and please stop buying hardware from two decades ago for a very high price 
1 Like
Hi @ms
āPlease run āchmod 755 /libā and that should fix at least something.ā
Do not working on my System.
I received always the Error:
āfirewall-dd openvpnserver[16071]: 2.247.249.12:2042 WARNING: Failed running command (ātls-verify script): could not execute external programā
I canĀ“t upload my Logfile because IĀ“m new in this Community 