Check to see what the librenms.log file says now, and re-run validate.php to check all tests are still ok.
if you still see permission errors in librenms.log, you might need to double check your webserver user ps aux | egrep ‘(apache|httpd|nginx)’
and make sure that /opt/librenms/storage/framework/cache/data folder is recursively owned by that user.
Nope, no luck.
Tried it in incognito mode on:
openSuSE leap (15.0)
os X 10.13.6
All failed.
or - if you have selinux enabled, I would re- configure the contexts needed by LibreNMS Cannot access WebUI
or try with selinux turned off, check with sestatus
I think your other post with fping6 might be related to this.
'been there, done that, no use.
librenms.log still says
2018-09-12 12:28:57] production.ERROR: ErrorException: file_put_contents(/opt/librenms/storage/framework/views/150fa18cabc0b9c27bb552ef57facdf4ccd4525f.php): failed to open stream: Permission denied in /opt/librenms/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:122
Stack trace:
#0 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, ‘file_put_conten…’, ‘/opt/librenms/v…’, 122, Array)
#1 /opt/librenms/vendor/lara (…)
but I’m not deep enough into Laravelle to be able to follow that (actually, I’m not in there at all).
./validate.php
| Component | Version |
|---|---|
| LibreNMS | 1.43-50-ge8cf6bb38 |
| DB Schema | 267 |
| PHP | 7.0.31 |
| MySQL | 10.0.35-MariaDB |
| RRDTool | 1.4.7 |
| SNMP | NET-SNMP 5.7.3 |
[OK] Composer Version: 1.7.2
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct
[FAIL] fping6 could not be executed. fping6 must have CAP_NET_RAW capability (getcap) or suid. Selinux exlusions may be required.
(bash: /usr/sbin/fping6: Keine Berechtigung)
[FAIL] fping6 should be suid!
[FIX] chmod u+s /usr/sbin/fping6
[FAIL] We have found some files that are owned by a different user than librenms, this will stop you updating automatically and / or rrd files being updated causing graphs to fail.
[FIX] chown -R librenms:librenms /opt/librenms
Files:
/opt/librenms/rrd/.gitignore
(… don’t mind the fping6 [FAIL], I already posted something about that issue in Possible Bug in validate.php )
Actually, if the stuff, that the three of us are trying right now, is the right spot, then the [FIX]-suggestion in the last line of the validate.php-output could be the origin of the problem. 'Cause after that recursive chown-command, my webinterface didn’t work anymore.
I don’t think so. The fping6 - problem existed from the first time on I ran validate.php and tried to fix that specific problem. That was sometime back in august and I just didn’t post it so far.
you could try run php artisan cache:clear apparently you need to run this after changing permissions on the laravel cache/data directory. I saw @jozefrebjak ran this earlier on his fix
No luck on php artisan chache:clear.
If you are getting a Whoops you may be having file permissions issues. Try:
chown -R librenms:librenms /opt/librenms
setfacl -d -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache/ /opt/librenms/storage/
setfacl -R -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache/ /opt/librenms/storage/
As we say in Germany: “Two id…s, one thought.” I just stumbled upon the permission acl changes during install. Voilà, works like a charm.
But because we tried the chown -R libren... before, I’ve got to mention, that the chmod -R g+w ...-line you wrote is the essential one.
On my system I tried a
setfacl -R -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache/ /opt/librenms/storage/
just like in the Ubuntu install instructions, which did the same.