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
1 Like
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.
1 Like
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
/usr/lib/samba
/usr/lib/python3.8
/usr/lib/cups
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).
1 Like
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