Don’t worry about this. This is a warning because the certificate is a self signed one. That is why you will have had to accept it in the past.
This message is worrying. It suggests that either that library file is not present or it has the wrong permissions.
The file should be in
Have a look in that directory and see if that lib file is present and if it is what its permissions and owners are.
On my system the file is present and has the following permissions
-rw-r--r-- 1 root root 589K Nov 14 2020 libgcc_s.so.1
libgcc_s.so.1 is located at /usr/lib with the same permission as yours:
-rw-r–r-- 1 root root 603008 Dec 18 2020 libgcc_s.so.1
/usr/lib has these permissions:
drwx------ 50 root root 36864 May 4 13:20 lib
Hmmm. I don’t understand that then. As your httpd/error_log is full of those messages about libgcc_s and mine is not.
Hopefully someone else can help further. I don’t have any further thoughts about this at the present time but will come back if I think of anything.
I found a similar topic here:
Is the change of permissions described there the correct solution from security point of view?
Just hit this bug today.
I solved it, together with other related bugs (HTTP 5xx errors, OpenVPN no longer working, etc.), simply by correcting several directory permissions, e.g. /usr/lib, /usr/sbin, /usr/lib/perl/* and some others I forgot to write down, silly me.
They all were with 700 permissions instead of 755, which prevented Apache, OpenVPN, Perl CGI scripts, etc., which run under “nobody” uid, to access needed files and libraries.
Hope this helps others to avoid reinstallation.
Could you manually change this back to 755?
chmod 755 lib
Can still not access the WebUI despite apache has been restarted.
How about /usr/bin? Do I also need to change the permissions to 755?
After changing the permissions of /usr and /usr/bin to 755 I get
[Tue Jul 20 15:40:22.693657 2021] [cgid:error] [pid 32612:tid 128405781583424] (13)Permission denied: [client 192.168.1.4:59456] AH01257: unable to connect to cgi daemon after multiple tries: /srv/web/ipfire/html/index.cgi
My /usr/bin has 755 so if yours has 700 then yes change that one also.
What are the permissions of /var?
I just inspected /usr/lib.
Some lib* files have only the -rw-r–r-- permission, but most of them have also a link pointing at them with the ‘right’ permissions. libgcc_s.so.1 lacks this.
Is this a possible reason for the error messages?
drwx------ 15 root root 4096 Jul 15 21:52 var
/var/ipfire permission look also strange:
drwx------ 52 root root 4096 Jul 15 21:52 ipfire
Yes, /var and /var/ipfire also look incorrect. Please change them to 755, too.
OK, after changing the permissions of /var and /var/ipfire to 755 I can log into the WebUI again
Thanks for your great support!
However, what worries me is why were the permissions set all wrong? Any idea?
The necessary permission changes were as follows:
1003 chmod 755 lib (/usr/lib)
1004 chmod 755 bin (/usr/bin)
1013 chmod 755 /usr
1032 chmod 755 /var
1038 chmod 755 /var/ipfire
I suspect a big in tar which we might have fixed with Core Update 158, however the update was installed with Pakfire from the previous version, so we will only know after the next update. Could you maybe upload /var/log/pakfire/upgrade-core-update-158.log? Maybe that will tell us something.
Here we go
update-core-upgrade-158.zip (9.0 KB)
For me as a non expert, there is nothing suspicious inside …
Unfortunately, I found another issue that is now failing after the upgrade to core 158: openvpn
I am sure that the openvpn connection worked with core 157 since I updated the certificates newly a couple of days ago. Now I am getting the error message on my mobile phone ‘Authentication failed User authentication failed’.
Which incorrect permissions could cause this failure?
In /var/log/messages I can see this error message:
OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/(deleted here)
WARNING: Failed running command (–client-connect): external program exited with error status: 1
The openvpn issue could be fixed by manually setting the wrong permissions of
to 755. All three had the wrong permission 700.
Another positive effect of these corrections is that avahi is now starting properly This was one of my initial observations (see above).
are there commonalities with this issue?
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.
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.