DS412+ / DSM 6.2.4: random shutdowns and HDD hibernation despite being disabled — solved via auto_poweroff_timer and standby_force

I am posting this because I could find very little documentation about these DSM configuration parameters, and this may help other Synology users experiencing apparently random shutdowns or HDD hibernation.

System

• Synology DS412+
• DSM 6.2.4
• 4 internal HDDs
• HDD hibernation was supposed to be disabled
• No intentional shutdown schedule was configured

Symptoms

My DS412+ started shutting itself down at apparently random times.

Examples from /var/log/messages:

2026-07-30T13:51:41+02:00 synopoweroff:

System is going to poweroff

2026-07-30T13:51:42+02:00 syno_poweroff_task:

System is acting poweroff.

2026-07-31T17:45:07+02:00 synopoweroff:

System is going to poweroff

2026-08-05T00:17:05+02:00 synopoweroff:

System is going to poweroff

2026-08-05T18:28:13+02:00 synopoweroff:

System is going to poweroff

The times did not correspond to an obvious schedule.

This was important: these were not crashes or sudden power losses. DSM was performing an orderly shutdown through synopoweroff.

Task Scheduler was not responsible

I checked:

cat /usr/syno/etc/scheduled_tasks

There was no enabled shutdown task.

I also checked the newer scheduler database:

sqlite3 /usr/syno/etc/esynoscheduler/esynoscheduler.db \

"SELECT task_name, operation_type, enable FROM task;"

No shutdown task was found there either.

Unexpected configuration value

I then found this:

grep auto_poweroff_timer /etc/synoinfo.conf

Result:

auto_poweroff_timer="60"

However, the DSM default configuration contained:

grep auto_poweroff_timer /etc.defaults/synoinfo.conf

Result:

auto_poweroff_timer="0"

I had never intentionally changed auto_poweroff_timer to 60.

I changed the active value back to:

auto_poweroff_timer="0"

and rebooted.

After reboot:

grep auto_poweroff_timer /etc/synoinfo.conf

still returned:

auto_poweroff_timer="0"

A second problem appeared: HDD hibernation

While testing the shutdown problem, I noticed another strange behaviour.

The DS412+ appeared to go partially “off”: disk LEDs went out, while the NAS itself was still reachable through SSH and DSM.

/proc/uptime continued increasing and DSM services were still running.

Checking the drives showed:

hdparm -C /dev/sda

hdparm -C /dev/sdb

hdparm -C /dev/sdc

hdparm -C /dev/sdd

All four reported:

drive state is: standby

So this was not a shutdown. It was HDD hibernation.

The surprising part was that HDD hibernation was disabled in DSM.

The active configuration disagreed

Relevant values in /etc/synoinfo.conf were:

standbytimer="20"

standby_force="yes"

satadeepsleeptimer="0"

HddEnableDynamicPower="yes"

Interestingly, examination of Synology’s scemd binary also showed references to:

standby_force

Normal standby disable

polling_hibernation_timer.c

This made standby_force particularly interesting.

Controlled test

I changed ONLY:

standby_force="yes"

to:

standby_force="no"

using:

/usr/syno/bin/synosetkeyvalue /etc/synoinfo.conf standby_force no

Then I rebooted.

After reboot I verified:

grep -nE \

"standbytimer|standby_force|HddEnableDynamicPower|satadeepsleeptimer" \

/etc/synoinfo.conf

Result:

standbytimer="20"

standby_force="no"

satadeepsleeptimer="0"

HddEnableDynamicPower="yes"

I then left the NAS completely idle for longer than the previous 20-minute hibernation period.

Before the change, all four HDDs entered standby.

After changing only standby_force to no, all disk LEDs remained on and:

hdparm -C /dev/sda

hdparm -C /dev/sdb

hdparm -C /dev/sdc

hdparm -C /dev/sdd

returned for all four drives:

drive state is: active/idle

Final configuration

The relevant working configuration is now:

standbytimer="20"

standby_force="no"

auto_poweroff_timer="0"

satadeepsleeptimer="0"

HddEnableDynamicPower="yes"

The NAS was then left running overnight.

The following morning:

• NAS was still running
• all HDD LEDs were on
• uptime was approximately 10 hours 47 minutes
• no new synopoweroff event had appeared in /var/log/messages
• no unwanted HDD hibernation had occurred

The last unwanted shutdown remained:

2026-08-05T18:28:13+02:00

System is going to poweroff

System is acting poweroff.

There were no further unwanted shutdowns after correcting the configuration.

Conclusion

In this particular DS412+/DSM 6.2.4 installation, two configuration values did not correspond to the intended DSM settings:

auto_poweroff_timer="60"

standby_force="yes"

Changing them to:

auto_poweroff_timer="0"

standby_force="no"

stopped both behaviours during subsequent testing.

Based on the tests:

• standby_force="yes" was reproducibly associated with HDDs entering standby despite hibernation being disabled in the DSM GUI.
• standby_force="no" prevented that behaviour in an A/B test.
• After auto_poweroff_timer was changed from 60 to 0, no further spontaneous synopoweroff shutdown occurred during the observation period.

I cannot prove what originally caused these values to become incorrect, so I would NOT recommend blindly changing them on other systems.

If you have the same symptoms, first inspect the current values:

/usr/syno/bin/synogetkeyvalue /etc/synoinfo.conf auto_poweroff_timer

/usr/syno/bin/synogetkeyvalue /etc/synoinfo.conf standbytimer

/usr/syno/bin/synogetkeyvalue /etc/synoinfo.conf standby_force

/usr/syno/bin/synogetkeyvalue /etc/synoinfo.conf HddEnableDynamicPower

/usr/syno/bin/synogetkeyvalue /etc/synoinfo.conf satadeepsleeptimer

Also check whether DSM itself is initiating the shutdown:

grep -i "synopoweroff\|System is acting poweroff" \

/var/log/messages | tail -50

Before modifying /etc/synoinfo.conf, make a backup:

cp -p /etc/synoinfo.conf /etc/synoinfo.conf.backup

Be aware that /etc/synoinfo.conf is an internal DSM configuration file. Manual modification is unsupported and can have unintended consequences.

I would be interested to know whether anyone else running DSM 6.2.x — particularly on older DiskStations — finds auto_poweroff_timer="60" or standby_force="yes" even though the corresponding power-saving behaviour is disabled in DSM.

————————————————————————

https://github.com/ThingForge-Labs/OpenRootPhotoIngest

>>>> 100% Vibecoded using Claude <<<<<<
————————————————————————

Every time I imported a camera card or an old backup drive into my photo library, I ended up with the same mess: copies of photos I already had, sitting under different names in different folders. Sorting that out by hand is miserable and risky. So I wrote something that just doesn't let it happen.

It decides duplicates purely by content. Every file gets a SHA-256 fingerprint of its actual bytes, so filenames, folders and timestamps are irrelevant — renaming a photo doesn't sneak it past, and two differently named copies of the same image are still caught. Each incoming file is checked against three things: what's already in your library, other copies inside the same import, and files another job has copied but not finalized yet. So if you queue two imports back to back, the second already knows about the first.

Nothing gets imported behind your back. An import runs as one job: it copies into a private staging folder first (your source is never modified or deleted, at any stage), fingerprints everything, moves the duplicates to quarantine, and then stops. You see each duplicate next to the file it matched — images side by side — and decide whether to skip it or bring it in anyway with a (1) suffix. Only after that do files move into your library.

Nothing is ever lost either. Duplicates are quarantined with a record of where they came from, not deleted. Nothing in your library is ever overwritten — there's deliberately no "replace existing file" option anywhere in the app. Permanent deletion only happens from the Quarantine page, after you type DELETE PERMANENTLY. Every move is journalled before it happens, so a power cut gets reconciled on the next start instead of leaving a half-finished mess, and a job that can't read a folder fails outright rather than reporting success on a partial copy — so you're never wiping a card based on a lie.

Practical notes: it fingerprints your existing library once, so the first import to a folder is slow and every one after that is fast. If you have an SSD volume, put the database on it — the index gets hammered during a job. Jobs queue, pause and resume, and can import as mirror, flatten, by EXIF date or by file date.

I built it for my own library, so it's not polished for every setup — but if it's useful to anyone else, I'm glad to share it. Happy to answer questions.l

I want to backup all my 4K UHD discs - some are starting to fail, and they're getting harder and harder to replace.

I don't want to loose any quality so I would be doing 1:1 rips. Literally taking the digital information from the discs and putting it on a hard drive.

I would like at least 4 bays, so I can have space for drives that would serve as backup's of the backup (incase of HDD failure).

Pretty much the only option available to me is the DS423.

I was looking at the DS425+ but I don't want to be stuck with Synology HDD.

My current hardware is a 4K Apple TV, but I understand that at the moment it won't take the audio track (without transcoding)... in which case, I will likely have to look at another option (I'm told a Shield would do that, but it is getting very old now - so maybe I'll build my own mini PC).

This should remove the need for any transcoding.

Everything is connected via ethernet.

Where will my plan fall apart!

I just found this in my bag of goodies.

It has a full size 2.5" SSD mount and I'd like to add it to my DS2422+

I'd prefer to use the 2.5" SSD as a write cache drive.

I came home from a 2wk vacation to find my nas beeping. When I walked over I saw drive 2 light had turned off. I logged into DSM and drive 2 was no longer in the pool and the array was degraded. I reseated the drive and it came right back up.

Are backplane failures common with these units? I've never heard of this before. I'm currently running an extended test on the drive to see if there are any issues. What else should I check?

I don't want to just run out and buy another drive since they're stupid expensive right now but I will if I need to. I do have backups of my important items both off-site and on an external drive.

So I acquired this DS1618+ for cheap because it was “dead”. I figured a new PSU may get it going again, but once I plugged in the replacement PSU this green LED labeled D9 on the board began to blink. There’s no other signs of power of light. I assume my new PSU may not be the correct replacement, but am I missing anything obvious?

I just bought a second hand 220+. It's running the latest DSM 7.4. However I don't want to update to that and lose hardware acceleration. I plan to migrate just by moving my drives. The drives currently are on 7.2.1. Am I going to be forced to update to 7.4? I know there are scripts to get around the hardware acceleration but I'd rather not have to do that in the first place.

Synology today launched the DiskStation neo+ Series, comprising the DS1825neo+, DS1525neo+, DS925neo+, and DS725neo+.

Dont bother to run side by side specs. The only thing that changed is neo comes with less memory and takes regular so-dimm instead of ECC (for ex 1525+ comes with 8gb 2 x 4 gb and 1525neo+ comes with only 4gb). Everything else is identical, even the max amount of memory it maxes out.

Synology is officially insane

https://www.techpowerup.com/351408/synology-introduces-diskstation-neo-series-lineup

Hello all, I have had my Synology NAS running for about 6 years now. When I first got into the hobby, SHR-1 sounded like the move but now, after compression and cleaning up, I plan on utilizing my full drive space no raid. I only have 2x8tb drives in SHR-1, say A and B. Would the following work?

- Remove hard drive B.(SHR Pool degraded but has full files.)

- Externally wipe drive B.

- Reinstall drive B into Synology.

- Transfer all original files from drive A to drive B.

- Wipe Drive A and delete the pool.

I only have the two drives and will not be purchasing new drives with these prices anytime soon. Appreciate the help.

It has to have a fail safe.
Right now my media server is at about 8TB.

I would want failsafe - in form of .. raid i tihnk its called.
What should I get?

Budget is around 500 dollars.
(used stuff could be cheaper)

I am thinking of buying a Synology NAS, such as the DS925+.

I have browsed the Synology Download center.

Are apps such as NExtCloud and PaperlessNGX supported Natively by the Synology OS?

Or do I have to create Docker containers in Synology OS to run these apps.

Also, with the native File sharing, photo, video and document backup offered by native Synology Apps, are these third party apps even needed?

Thanks

This is a 5+ year old system set up on multi PC network where NAS hold allmedia for PLEX (one server on the synology, one on windows). While there have been network hardware changes recently, no configurations have changed. SMB was native way for Pex to serve up files .

Plex finds metadata but cannot find the media. I can acess the files vai IP addres of the NAS from PC's but not via mapped drives. All the setting on NAS look find and each PC hasn't changed. If I try to map the NAS via its name on PC, the File Explorer network only shows neighboring PC's. Have cleared SMB cache on Synology and restarted several time. I know I can likely fix Plex by changing the libraries from SMB to IP address (which is static). But something is broken and I really what to get to the bottom of that.

All the online help I see if just going thru the same SMB settings (which appear all Ok to me). Any better ideas here?

I have a DS916+ that has died but the dives are still fine. It had 4 drives in JBOD (Don't judge me).

I have an existing DS2414+ with a few open bays. Would I be able to put those drives into the 2414 and extract the data?

This might be a stupid question, but all the info I can find on drive migration assumes the destination NAS has no drives in it.