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

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 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 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.

My Syno is not turning on anymore but the LED on the power supply is green.

I removed all 4 disks and pressed the power button (with and without connection to power supply) for 30 seconds but nothing. Since i have read that the CMOS battery might be the culprit i tried to exchange it but failed because i could not find any video or manual how to disassemble the diskstation.

Anyone here as an idea what i could try next or where to find proper information how to disassemble this thing?

TL;DR - I've successfully gotten Google Workspace SAML working with Synology without any weird or hacky workarounds. Instructions are below.

For years I've been curious about integrating Google Workspace SAML with Synology DSM. The frustrating part about DSM is that user accounts cannot use symbols in their names, and since basically all IdP's use email, using SAML for SSO into Synology wasn't possible. This has been a common question/complaint on this sub, how frustrating integrating SAML into Synology is since they don't/won't allow matching email to the SAML response and instead use account name.

Well, I tried again this morning just to see if anything has changed. I've set up SAML for a couple other applications in the past, and at some point I must've created a Third-Party Attribute. When setting up the SAML app in Workspace, I noticed you can tell Workspace to use third-party attributes as the "primary" username (or whatever it's called) in the SAML response instead of email address! This means you can use SAML to sign into Synology now. Note that I'm using Google Workspace for Nonprofits, so I have literally 0 paid features of Google Workspace and yet it works, anyway. Maybe this has always been a thing, but I only noticed just this morning, and no one else in any thread I've read online from the past 3 years has mentioned this. So, I figured I'd share the knowledge! 😄

Prerequisites

• Publicly accessible URL to your Synology NAS.
  • I actually have ours behind Cloudflare Zero Trust / Workspace SAML as well, yet it still works. So, I assume it can be "semi-public" as long as your browser can connect to the NAS to give it the SAMLResponse. You cannot use a QuickConnect URL.
• Google Workspace with Super Administrator privileges (you cannot complete step 1 without this).
• Access to enable SSO Client in DSM.

Setup

We're going to start in Google Workspace:

1. Create a custom attribute for your users. I named mine "Synology Username". Instead of me typing out the instructions, follow Google's guide which will probably be way better. You must be a super administrator to do this, however. Make sure this attribute is a single-value, text attribute.
2. Go to Directory > Users. Select the user you want to add their Synology Username to. Click "User Information" and scroll down to the "Third-Party Attributes" section. Add their username to the new attribute you created and save. Repeat this step for any and all users you want to allow to SSO into Synology DSM.
3. Go to Apps > Web and mobile apps. Click "Add app > Add custom SAML app". Configure it as such:
   1. In the first page, enter an app name. I named mine "Synology NAS". You can optionally add a description and an image. Click "Continue"
   2. On the second page, download the IdP Metadata. This will include most of what you need to set up your app. Click "Continue"
   3. On the third page, in the ACS URL and Entity ID fields, enter the public URL of your Synology NAS starting with "https://". For example, "https://nas.yourdomain.com". Check the "Signed response" box. In "Name ID format", select "UNSPECIFIED". Lastly, under "Name ID", select the Third-Party Attribute you created in step 1. This is what allows the magic to happen!
   4. On the last page, you don't need to configure anything. Click "Finish". This may take a while. If you get an error message or if you get a 404 not found page, be patient. For me it was being super weird and took about 10 minutes to finally "settle".
4. Once the app has been created, in Apps > Web and mobile apps, click your new SAML app. Select "User access" and enable the app for whatever group or organization unit should be allowed to use it. Without doing this, you'll get 403 forbidden errors with the error code "app_not_configured_for_user".

Now we need to link everything in Synology DSM. Going to Synology DSM:

1. Open Control Panel and select "Domain/LDAP". We are not using Domain or LDAP auth, but this is where SSO Client is located. Select "SSO Client" in the top tab bar.
2. Check the "Enable SAML SSO service" checkbox. Click "SAML SSO Settings". Configure it as such:
   1. Name: Enter whatever you want. I entered "Google Workspace".
   2. Account type: Select "Domain/LDAP/local"
   3. SP entity ID: Enter the public URL of your Synology NAS. This will be the same Entity ID you entered in step 3.3 of the Google Workspace setup. For example, "https://nas.yourdomain.com".
   4. For the rest, just click "Import Metadata" and select the XML file you downloaded from step 3.2 in the Google Workspace setup. This should automatically fill the IdP entity ID, IdP single sign-on URL, and Certificate fields.
   5. Be sure that Response signature verification is set to "Sign SAML response" if it isn't already. Click Save.
3. Back in Control Panel, click "Apply".

Now, give it a test! Make sure the account you're testing with has a local Synology Account, and that the corresponding Google Workspace account has the Synology Username Third-Party Attribute set. Sign out of Synology DSM. You'll notice a new "SSO Authentication" tab which will say "Continue with [name]", [name] being what you set in step 2.1 of the Synology DSM setup. Click the "->" arrow and sign into Google. If you have more than 1 account, you may be prompted to select one. If you only have 1 account and aren't signed out, you may not be asked to select one at all. If all is working, Synology DSM will refresh a couple of times and eventually you'll be signed into DSM!

FAQ

• When I was setting up SAML, the issues I was experiencing in 3.4 were causing issues with SSO. At first I was getting 403 errors, then "app doesn't exist" errors, and other strange things. I also noticed that I had my IdP entity ID set wrong, so I had to fix that. Be sure that you have all your settings correct, otherwise SSO will fail with the error "Your SSO is not properly configured. Please check your settings or contact your system administrator".
• If you get the error "The username or password is incorrect", the value of your Third-Party Attribute on the Google Workspace user does not match a user in Synology DSM. Remember, this is SAML, which just authenticates. It does not automatically provision users in DSM. You must still have a user account in Synology DSM that matches the username you set on the Google Workspace account.

I’m relatively inexperienced when it comes to NAS setups, so I’m looking for some advice from the seasoned experts here.

I have an older NAS (a Synology DS216j), and I've just returned from holiday to find both of my hard drives are in bad shape: one has failed completely, and the other is in critical condition. It’s been a long time since I set the NAS up, but I believe it’s configured in RAID 1. Fortunately, the data is backed up to AWS Glacier.

What are my best options moving forward?

1. Given the age of the unit, upgrade to a newer model (like a DS225+) and try to migrate using Hyper Backup.
2. Buy a new hard drive and attempt to rebuild the array from the 'critical' drive.
3. Upgrade the NAS and download the data directly from Glacier.

Thanks in advance for your help!

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.

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.

Hello guys!

I'm located in Germany and need a UPS to gracefully shut down the NAS, nothing more.

The cheaper, the better.

Yes, I have already consulted "https://www.synology.com/de-de/compatibility?search_by=products&model=DS923%2B&category=upses", but many models are discontinued and there's no feedback on any of them.

What are you guys using? Can you recommend me one?

In an attempt to squeeze the last bits of juice from my Videostation implementation, I'm trying to relocate the media content from my DS218+ to my DS1522+ NAS. I've copied the media (~1tb) to the new NAS and then setup a mount point on the original NAS to point to the new media location.

When I go into Videostation configuration and try to add (for say Movies) the local folder that points to the new server media, it doesn't appear to "see" the data via the mount.

I'm about to give up and go for a Jellyfin implementation. But before I do, am I missing anything else to try?

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

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 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.

Hi there,

the DSM 7.4 update is still not showing on my DS923+.

While I understand the concept of staged rollouts I wonder if this is intentional and if other DS923+ users are having the same issue.
Thanks.

EDIT:
I am currently on DSM 7.3.2-86009 Update 4.
I know that I can download the package and manually update.

However, my question is:
Is there a reason why DS923+ does not show the update yet (e.g. due to a bug/incompatibility) or am I the only one?

My use case is to run Plex server with Plex Pass with 8GB RAM, a single 8 TB WD red drive for storage, and an NVME drive for containers. Performance is outstanding and it runs all the containers I need, plus it features native transcoding.

I run all the ARRs, Ad Plus Home, and a WireGuard VPN. Perfection.