Unifi Webgui Repair

Chances are if you run the following setup to harden the Ubiquiti Unifi setup after following instructions at Ubiquiti forum, you are likely to run into problem after each update.

The forum article to harden Unifi setup is here "Linux  Unifi Controller default Debian setup is grossly insecure:

https://community.ubnt.com/t5/UniFi-Feature-Requests/Linux-Unifi-Controller-default-Debian-setup-is-grossly-insecure/idi-p/1752863 

The steps include the following:
1) systemctl stop unifi
2) groupadd unifi
3) useradd -g unifi -s /bin/false -d /dev/null unifi
4) chown -R unifi:unifi /var/log/unifi /var/lib/unifi
5) rm -rf /var/run/unifi
6) cat > /etc/systemd/system/unifi.service.d/security.conf <<EOF
[Service]
RuntimeDirectory=unifi
User=unifi
Group=unifi
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
EOF
7) systemctl daemon-reload
8) systemctl start unifi


If you run Fail2ban, it probably shows an error and you need to edit the logpath in /etc/fail2ban/jail.local under [ubiquiti] with the 'logpath = /var/log/unifi/server.log'. The Unifi Webgui may fail to run too (but this is likely an isolated issue).
 
Error message that unifi fail to make links to default path to /usr/lib/unifi/data, /usr/lib/unifi/logs, /usr/lib/unifi/run: 

unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/data': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/data': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/logs': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/logs': No such file or directory
unifi.init[1630]: ln: failed to create symbolic link '/usr/lib/unifi/run': Read-only file system
unifi.init[1630]: chown: cannot access '/usr/lib/unifi/run': No such file or directory
unifi[1726]: log4j:ERROR setFile(null,true) call failed.
unifi[1726]: java.io.FileNotFoundException: logs/server.log (No such file or directory)

Run the following commands to link the /var/*/unifi folders to /usr/lib/unifi/* folders:

sudo ln -s /var/log/unifi/ /usr/lib/unifi/logs
sudo ln -s /var/lib/unifi/ /usr/lib/unifi/data
sudo ln -s /var/run/unifi/ /usr/lib/unifi/run

The following error now appears because of the symlink made above using 'ln -s'.

unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/data': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/data': Read-only file system 
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/logs': Read-only file system
 unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/logs': Read-only file system
unifi.init[9175]: rm: cannot remove '/usr/lib/unifi/run': Read-only file system
unifi.init[9175]: chown: changing ownership of '/usr/lib/unifi/run': Read-only file system

If the Webgui is not up, it turns out that mongodb.service is not active.

Hence, run :
systemctl restart mongodb.service

If there is problem in setting up the access permissions of the folders or files: it is good to set stricter permission at the downstream level. For example, setting /usr/lib/unifi to 755 where owner has 'rwx' permission, user belongs to a group has 'rw-' permissions and other users not in the group has 'rw-' permission. On the other hand the symlink target of /usr/lib/unifi/data and /usr/lib/unifi/logs may have another set of access permissions, such as setting /var/lib/unifi and /var/log/unifi to 700 where only owner has 'rwx' permission. Going downstream, the permissions settings of /var/log/unifi/server.log may have stricter permissions of 600 where the user has only 'rw-' permissions.

NB: 'r' stands for read access, 'w' stands for write access, and 'x' stands for execute access.

Update 20 March 2018:

With the latest update to 5.7.20-10627:
There is a bug reading  " Cannot open PID file /var/run/unifi.pid ". I managed to fix it by editing  /usr/lib/unifi/bin/unifi.init, specifically changing the following line of PIDFILE:

#originally PIDFILE is directly placed directly under /var/run
#PIDFILE="/var/run/${NAME}.pid"
#now it is edited to include under another layer under ${NAME}
PIDFILE="/var/run/${NAME}/${NAME}.pid"

Follow my blog with Bloglovin