Recently, I replaced the Uninterruptible Power Supply (UPS) connected to my Synology with an APC BX2200MI. During setup, I ran into some typical Synology shenanigans, which I managed to work around. I documented them here for anyone else who might encounter the same issues (and as a note to my future self).

Add More Than Five ‘Permitted DiskStation Devices’ (a.k.a. NUT Clients)

If you have multiple devices connected to your UPS that you’d like to shut down safely in the event of a power outage, your Synology can act as a ‘network UPS server.’ Under the hood, Synology runs Network UPS Tools (NUT), an open-source UPS monitoring tool. NUT works with thousands of UPS devices and on many operating systems. You’re therefore not limited to connecting only Synology appliances to your UPS; any machine that supports NUT can be shut down safely.

In my case, I’ve also connected a couple of servers, as the UPS has enough capacity for them. However, you need to allowlist (i.e., permit) the IP address of each “NUT client” that’s allowed to retrieve the UPS status from your Synology. Unfortunately, the Synology DSM web interface limits the number of “Permitted DiskStation Devices” to five, but this is an arbitrary Synology limit, not a NUT limit.

If you need to allowlist more than five NUT clients, you can do so by logging in to your Synology via SSH and editing the following file as root:

/usr/syno/etc/ups/synoups.conf

Add the IP addresses in the same format as the first five entries. The Synology web interface will still only display the first five, but additional clients will work just fine! Note: Changing any UPS setting in the Synology web interface will overwrite the file and remove your extra IPs, so try to avoid making further changes there.

Don’t forget to restart the NUT UPS daemon to apply your changes:

sudo synosystemctl restart ups-usb

Pro tip: The default NUT username on Synology is monuser with the password secret. If you need more information on configuring a non-Synology NUT client, take a look at this gist: https://gist.github.com/jhelmink/ba54e11e6a1b9f448a4a9a5c4cb45b89

Change UPS Parameters

By default, most UPS units come with parameters defining what qualifies as “low battery.” For my specific APC UPS, it is set so that 10% battery charge or 120 seconds of runtime remaining will trigger a “low battery” status, which in turn signals the Synology (by default) to shut down cleanly to prevent data loss. You can see these values by running:

upsc ups@localhost

(from an SSH session on your Synology).

I wanted to adjust these parameters. My main reason for owning a UPS is to protect data rather than maintain uptime during an outage. Ten percent battery charge (or just two minutes) before initiating shutdown seems too tight because it takes my Synology some time to stop all processes, spin down disks, and power off safely. Also, if power returns, causing the Synology to reboot, and then goes out again, I want enough runtime left for another clean shutdown.

If you have only one or more Synology devices connected to your UPS and no additional (vanilla) NUT clients, you can skip the steps below and simply use the Customize time option built-in Synology DSM. Keep in mind, however, that this setting is client-side. If you do have other NUT clients, you’d need to configure each client individually, which can be more work than ticking a single box in DSM. Therefore, if you plan to shut down multiple devices after running on battery for a certain number of minutes, I recommend updating these parameters directly in the UPS firmware. That way, if you unplug the UPS and connect it to another system in the future, the configured value will remain in the UPS itself.

To modify these parameters in the UPS firmware, you could use the official tooling—PowerChute for APC devices—but that means unplugging the UPS from your Synology and connecting it to a Windows PC. However, because Synology uses NUT under the hood, we can also use NUT’s upsrw command to do this remotely. The catch is that Synology’s firmware omits upsrw, so you’ll need a separate Linux machine that does have upsrw in order to connect to your Synology’s NUT server and change the UPS parameters.

Adding a NUT Admin User

Synology hardcodes a single NUT user (monuser) and does not provide an admin account by default. To change firmware parameters, though, you’ll need a NUT admin user. To create one, log in to your Synology over SSH as root and edit:

/etc/ups/upsd.users

Add the following section at the bottom:

[admin]
password = YourNewPassword
actions = SET
instcmds = ALL

Then restart the NUT service:

sudo synosystemctl restart ups-usb

Changing the UPS Parameters

From your Linux machine (the one with upsrw installed), first check which UPS parameters are configurable:

upsrw ups@<YOUR_SYNOLOGY_IP>

You might see something like this:

[battery.charge.low]
Description unavailable
Type: STRING
Maximum length: 10
Value: 10

[battery.runtime.low]
Description unavailable
Type: STRING
Maximum length: 10
Value: 120

[input.sensitivity]
Description unavailable
Type: STRING
Maximum length: 10
Value: medium

...

To change, for example, battery.runtime.low to 300 (i.e., the UPS will trigger a shutdown at 300 seconds of remaining runtime):

upsrw -s battery.runtime.low=300 -u admin -p YourNewPassword ups@<YOUR_SYNOLOGY_IP>

This sets the value in the UPS firmware, so the setting persists even if you later move the UPS to another system.

Once you’re done making changes, remember to restart NUT on your Synology:

sudo synosystemctl restart ups-usb

If you no longer need the admin account, simply remove the section you added to /etc/ups/upsd.users and restart NUT again.

Double-Check UPS Compatibility

This may be obvious, but always verify that your UPS is compatible with your specific Synology model. In my case, I have two NAS units: a DS918+ and a DS218Play. Initially, I plugged the UPS into the DS918+. Although it seemed fine at first—values were read correctly—the Synology soon started reporting that the UPS was constantly going offline and back online with no clear cause. Replugging the USB cable and rebooting didn’t help.

After consulting the Synology Compatibility List, I noticed the DS918+ isn’t listed for my UPS model, but the DS218Play is. Sure enough, once I plugged the UPS into the DS218Play, the random off/online flapping immediately stopped.

This guide explains how to shrink an ext4 disk with a GPT partition table without using LVM, specifically using the QCOW2 disk format in Proxmox.

BACKUP YOUR DATA FIRST BEFORE ATTEMPTING THIS. YOU HAVE BEEN WARNED.

1. Check Disk Usage in the VM

In the VM, run:

df -h

Note down the actual usage of the disk you want to shrink (e.g., 250GB).

2. Shutdown the VM

Ensure the virtual machine is powered off.

3. Boot with GParted Live ISO

Load the GParted Live ISO and start the VM using this ISO.

4. Resize the Partition with GParted

In the GParted GUI, resize the desired partition. Leave some headroom—for example, if you noted 250GB in step 1, shrink it to 300GB.

5. Shutdown the VM Again

After resizing, shut down the VM once more.

6. Check the Current QCOW2 File Size on the Host

On the Proxmox host, navigate to the image directory:

cd /var/lib/vz/images/
qemu-img info vm-204-disk-1.qcow2

Note the current size of the QCOW2 file.

7. Shrink the QCOW2 File

On the Proxmox host, execute:

qemu-img resize vm-204-disk-1.qcow2 --shrink -1500G

Replace the filename and the size value (-1500G in this example) with your desired values. This command shrinks the disk from 2000G to 500G.

8. Verify the QCOW2 File Size

Confirm the file has been shrunk:

qemu-img info vm-204-disk-1.qcow2

9. Update Proxmox with the New File Size

Run the following to let Proxmox rescan and update the disk size:

qm rescan

10. Attempt to Boot the VM

When you try to boot the VM, it may fail with an error similar to:

ALERT! /dev/disk/by-uuid/xxxxxxxxx does not exist. Dropping to a shell

This error indicates that the GPT table is broken.

11. Fix the GPT Table

Boot into the GParted Live CD again and run:

sudo sgdisk -e /dev/sda

Although it may throw some warnings and complain, it should (fingers crossed) automatically fix the GPT table.

Note to self: It might be possible to execute step 11 directly after step 4 to avoid booting into the live CD twice. I’ll see if this can be done in future attempts.

12. Resize the Partition to Include Headroom

Once the GPT table is fixed, the VM should boot without issues. However, the partition will not be fully resized because of the headroom. To incorporate the headroom, run:

sudo growpart /dev/sda 2
sudo resize2fs /dev/sda2

Done !

The goal of the steps below is to resize (shrink) the ext4 partition /dev/sda2 and its disk /dev/sda below to 6.9T, so that they fit within the thin-LVM pool sized at 6.95T

Disclaimer: I have no idea what I’m doing, so follow these steps at your own risk.

1. Trim Unused Space

Inside the VM, run:

fstrim -a

This will save time during the disk operations.

2. Boot into GParted Live ISO

Boot the VM using the GParted Live ISO.

3. Resize the Partition

Use the GParted GUI to shrink the partition /dev/sda2 to the smallest size possible, leaving a little headroom.
Example:

4. Shutdown the VM

After resizing, the partition /dev/sda2 will now be smaller, but the disk itself (/dev/sda) will still be the original size. Let’s fix that. Shut down the VM.
Example:

5. Resize the Disk on the Proxmox Host

On the Proxmox host (hypervisor), resize the VM disk to fit within the thin-LVM pool:

lvreduce -L 6.9T /dev/media/vm-101-disk-0

Replace /dev/media/vm-101-disk-0 with your VM’s disk path.

Why 6.9T? My thin-LVM is 6.95T, so I left a bit of headroom to avoid overcommitting the pool.
Example:

6. Rescan the Disk in Proxmox

Run the following to make Proxmox aware of the new disk size:

qm rescan

Example output:

7. Attempt to Boot the VM

If you’re lucky, the VM will boot without issues. However, you’ll most likely encounter an error like:

ALERT! /dev/disk/by-uuid/xxxxxxxxx does not exist. Dropping to a shell

If this happens, boot the VM into the GParted Live ISO again. The GParted GUI will show all storage as unallocated, but don’t panic (famous last words).
Example:

8. Fix Partition Errors with gdisk

Open a terminal in GParted and run:

sudo gdisk /dev/sda

• Type v to verify the disk.
• You’ll likely see warnings or errors. Follow the on-screen instructions to fix them.
  • For example, I had to go to the expert menu (x), then press e, and so on, until all errors were resolved.
• Once everything is fixed, type w to write the changes to the disk and press Enter.
  Example:
  

9. Resize the Partition Back to Match the Disk

Open the GParted GUI again. This time, you can expand the partition to fill the resized disk.
Example:

10. Verify the Disk Layout

Check that the disk size and partition size match your desired configuration:

sudo fdisk -l

Example:

11. Check the Filesystem for Errors

Run a filesystem check to ensure no errors:

e2fsck -f /dev/sda2

12. Reboot the VM

Finally, reboot the VM. It should boot without any issues, and the disk and partition should now be sized as desired.
Example:

That wasn’t so hard after all… lol. I hope it helps