QNAP NAS - Error FW003 when trying to update firmware

Have you received error FW003 when trying to update the firmware of your QNAP Network Attached Storage (NAS)?
You have found the right page!
 
If you encounter error FW003 when trying to update the firmware of your QNAP NAS, it means that the system disk partition (which is used by the NAS to actually work and is separated from the actual storage space) does not have enough free space to perform the update operations. For example, if the size of the new version of the firmware is 185 MB and the available space is only 180 MB, you will get this error.
 
The only way to solve is to free enough disk space to perform the update. To do this you will have to connect to the NAS via SSH (using PuTTY on Windows, or a terminal on Linux/MacOS), and start looking for files that can be sacrificed to make room for the update.
 
To achieve this, once connected to the NAS via SSH, you will have to perform the following operations:
 

1. Confirm you have not enough free space on the system disk by issuing this command:
   
   [~] # df
   
   You'll get an output like the following:
   
   
   
   
   You have to check the column "Mounted on" and find "/mnt/HDA_ROOT". Check if available space is effectively smaller than the firmware update package. If so, go on. If not, contact QNAP support.
   
   
2. Confirm no /mnt/update file or folder and no /tmp/update_process file exist: if they exist, you need to delete them using:
   
   [~] # rm -rf /mnt/update
   [~] # rm -f /tmp/update_process
    
   
3. Repeat step 1. If available space on /mnt/HDA_ROOT is now larger than needed, proceed with the firmware update. If available space on /mnt/HDA_ROOT is still smaller than needed, proceed to Step 4.
    
   
4. Now you will have to look for the files that are occupying too much space on your /mnt/HDA_ROOT partition. This is different for every system, so there is not a unique solution. It's basically trial-and-error. Start with:
   
   [~] # ls -als /mnt/HDA_ROOT/
   
   To get the list of directories on this partition. Now check every directory using the following command:
   
   [~] # ls -als /mnt/HDA_ROOT/directoryname
   
   where directoryname stands for each directory (and their subdirectories) on the partition. My suggestion: start with the .logs and lost+found directories. For example:
   
   [~] # ls -als /mnt/HDA_ROOT/.logs
   
   You might get something like this:
   

   -rw-r--r-- 1 admin administ 184.7M Jan 21 2020 conn.log
   -rw-r--r-- 1 admin administ 345.3M Jan 18 2020 event.log

   As you can see those files have become huge, so you can safely delete them (they are log files, so not needed by the system) using the command:
   
   [~] # rm -f /mnt/HDA_ROOT/.logs/conn.log
   [~] # rm -f /mnt/HDA_ROOT/.logs/event.log
   
   As specified above, this is just an example. You will have to find the files that actually occupy too much space ON YOUR SYSTEM.
    
   
5. Once deleted these files, and freed up enough space, proceed with the firmware update as usual.

Easily create a VPN Gateway with a Raspberry Pi (or similar board)

I don't have an OpenVPN-capable router, but I needed to create an always-on openvpn CLIENT that would connect to my VPN service, so that it could be used as a gateway for other devices in my LAN. Using this gateway to access the internet, the internet traffic of those devices would be protected by the secure VPN connection.

I've looked around and I have found a great tutorial to achieve this: it was written by Superjamie for the Raspberry Pi and you can find it here.

Unfortunately I didn't have a Raspberry Pi available at the time, so I thought it would be interesting to do the same for what board I had available, which was an Orange Pi Zero.

I used DietPi as the base operating system for this project, and tried following Superjamie's tutorial, but since it didn't work on my Orange Pi / DietPi combo, I made a few adjustments, which I share with you here.
All credits for this still go to Superjamie, because that's where all the huge work comes from.

Please follow Superjamie's tutorial (again, you can find it here) with the following exceptions:

1. Install DietPi instead of Raspbian Jessie
2. Since DietPi's user already has root capabilities, you should write any commands from Superjamie's tutorial without typing the 'sudo' at the beginning of the command.
3. I've found out that the section of the tutorial called "Enable VPN at boot" was useless and harmful, as it would prevent OpenVPN to be launched correctly, therefore it must be skipped.
4. The VPN Kill Switch section of the tutorial didn't work for me. I have found out that it had to be modified a little bit to make it work, so I'm re-writing it below, in a version that makes it work:

VPN KILL SWITCH 

This will block outbound traffic from the Pi so that only the VPN and related services are allowed.
Once this is done, the only way the Pi can get to the internet is over the VPN.
This means if the VPN goes down, your traffic will just stop working, rather than end up routing over your regular internet connection where it could become visible.

[Note by Tech Delirium: please adjust IP addresses by using the correct ones for your network and the port numbers by checking the ports used by your VPN service]

iptables -A OUTPUT -o tun0 -m comment --comment "vpn" -j ACCEPT
iptables -A OUTPUT -o eth0 -p icmp -m comment --comment "icmp" -j ACCEPT
iptables -A OUTPUT -d 192.168.1.0/24 -o eth0 -m comment --comment "lan" -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 1198 -m comment --comment "openvpn" -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --sport 22 -m comment --comment "ssh" -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 123 -m comment --comment "ntp" -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -m comment --comment "dns" -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -m comment --comment "dns" -j ACCEPT
iptables -A OUTPUT -o eth0 -j DROP
iptables -I FORWARD -i eth0 ! -o tun0 -j DROP

[Note by Tech Delirium: Superjamie's tutorial didn't work for me, but adding the last line above does the trick and makes the kill-switch work]

And save so they apply at reboot:

sudo netfilter-persistent save

If you find traffic on your other systems stops, then look on the Pi to see if the VPN is up or not.

You can check the status and logs of the VPN client with:

sudo systemctl status openvpn@Japan
sudo journalctl -u openvpn@Japan

That's it! Now the board will connect to your VPN service at startup and if you set up you devices to use the Pi's as their gateway, that device's internet traffic will be tunneled via the VPN and will be protected. If the connection to the VPN service goes down, NO TRAFFIC will be allowed through, so you will have no leaks.

Slow shutdown/reboot when mounting CIFS/SMB shares on Ubuntu and derivatives

My laptop with Linux Mint 17.2 suddenly started taking full minutes for every reboot/shutdown. What might have caused it?

I then remembered I had previously placed some new entries in the fstab, since I needed to mount some remote CIFS shares. Could this be the culprit?

Well, it seems it was exactly that: there is a bug in Network Manager which shuts down before unmounting the network shares. This will cause CIFS to hang and wait for 60 seconds or so for every share.

Even though the Ubuntu Wiki says that this bug has been solved since version 12.04, I have applied the suggested solution and it worked.
Now the shutdowns/reboots happen in an instant!

So, is the bug back? I don't know, but what I know is that this is how to fix this problem:

sudo ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K14umountnfs.sh

sudo ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K14umountnfs.sh