F5F Stay Refreshed Software Operating Systems Yes, you can utilize your Synology NAS as an SNMP device to control power-down operations during low UPS levels.

Yes, you can utilize your Synology NAS as an SNMP device to control power-down operations during low UPS levels.

Yes, you can utilize your Synology NAS as an SNMP device to control power-down operations during low UPS levels.

T
tmt108
Junior Member
45
10-23-2016, 08:50 AM
#1
I just discovered my Synology NAS can connect to your APC UPS via USB. I’m curious about using SNMP—does it mean you can control or monitor the device? I’m not sure what options are available. I was thinking of turning SNMP on so my CentOS/Redhat servers can detect the UPS and automatically power it off during outages or surges, ideally with adjustable settings per device. Right now I rely on apcupsd running locally, which works well but needs some scripts and SSH access. If something goes wrong—like SELinux blocking a service—I might not get everything shut down in time before the UPS fails.
T
tmt108
10-23-2016, 08:50 AM #1

I just discovered my Synology NAS can connect to your APC UPS via USB. I’m curious about using SNMP—does it mean you can control or monitor the device? I’m not sure what options are available. I was thinking of turning SNMP on so my CentOS/Redhat servers can detect the UPS and automatically power it off during outages or surges, ideally with adjustable settings per device. Right now I rely on apcupsd running locally, which works well but needs some scripts and SSH access. If something goes wrong—like SELinux blocking a service—I might not get everything shut down in time before the UPS fails.

F
FamusLuna
Member
202
10-24-2016, 01:47 AM
#2
If you know apcupsd, consider deploying Docker on your NAS and executing it inside a container there.
F
FamusLuna
10-24-2016, 01:47 AM #2

If you know apcupsd, consider deploying Docker on your NAS and executing it inside a container there.

R
Rucian
Member
142
10-24-2016, 04:20 AM
#3
This could also work well!
R
Rucian
10-24-2016, 04:20 AM #3

This could also work well!

I
inboxcar
Member
182
10-28-2016, 05:11 AM
#4
Here’s a revised version of your text:

Just a piece of advice for those who know their way, Docker on Synology has some shortcomings. First, the Docker team now advise against letting Docker run containers with root privileges. Instead, set up a separate user and keep containers unprivileged. The problem lies in DSM not allowing you to use sudo to start a container from the interface, which leads to folder permission issues when mounting volumes inside containers. You might try creating a custom docker group, granting read/write access to the docker directory, and adding your admin user to it—but this is essentially what they recommend against. Another workaround is using SSH to run containers with sudo, though this removes the value of having a graphical interface. The second concern is more intricate and remains unclear to me; I haven’t figured out why or how to fix it yet. Subnets aren’t compatible—if you set up a Stack on a NAT network with a few containers, everything works fine. But when you attempt to create another stack on a different subnet, even with distinct addresses, the system reports an address pool is already in use and crashes. You can try bridging all traffic to the host as a solution, but this isn’t ideal for security and limits you to handling just one complex project at a time.
I
inboxcar
10-28-2016, 05:11 AM #4

Here’s a revised version of your text:

Just a piece of advice for those who know their way, Docker on Synology has some shortcomings. First, the Docker team now advise against letting Docker run containers with root privileges. Instead, set up a separate user and keep containers unprivileged. The problem lies in DSM not allowing you to use sudo to start a container from the interface, which leads to folder permission issues when mounting volumes inside containers. You might try creating a custom docker group, granting read/write access to the docker directory, and adding your admin user to it—but this is essentially what they recommend against. Another workaround is using SSH to run containers with sudo, though this removes the value of having a graphical interface. The second concern is more intricate and remains unclear to me; I haven’t figured out why or how to fix it yet. Subnets aren’t compatible—if you set up a Stack on a NAT network with a few containers, everything works fine. But when you attempt to create another stack on a different subnet, even with distinct addresses, the system reports an address pool is already in use and crashes. You can try bridging all traffic to the host as a solution, but this isn’t ideal for security and limits you to handling just one complex project at a time.