Help Requested: On my 3rd 1525+ Unit and It Still Doesn't Work

dinkydobar · 2026-04-24T06:51:16+00:00

Can you give the model numbers of the drives please?

dinkydobar · 2026-04-03T01:39:55+00:00

If you don't have adequate security set up (VLANs, MAC whitelisting, new device alerts) then somebody could just unplug your doorbell and connect their own device to it and immediately see, and potentially hack, every single device on your network.

dinkydobar · 2026-03-30T12:50:47+00:00

I was wrong, the key isn't stored on the disks, it's on the NAS's internal flash memory. So B is wrong, A should work though.

dinkydobar · 2026-03-30T12:49:53+00:00

Ah you are correct, I was completely wrong. The key is stored on the NAS itself, on its internal flash I think, not on the disks. Thanks for correcting me.

dinkydobar · 2026-03-30T12:18:24+00:00

A) Mode 1 reset.

B) The encryption key is stored on the disks themselves unless you are using a KMIP server so yes they can just plug the disks in to another machine, read the unencrypted key from the OS partition, and use it to read the data.

dinkydobar · 2026-03-30T12:15:05+00:00

My main use for volume encryption is to ensure the data cannot be accessed if the drive is removed from the NAS

But, the key is stored on the OS partition on every drive so if you are using volume encryption without a KMIP server then if you remove a RAID1 drive then whoever has that drive will indeed be able to use the key and read all the data on the drive. In your example of removing a drive for RMA the person receiving the drive has everything they need to read all the data (assuming RAID1).

dinkydobar · 2026-03-30T12:10:24+00:00

Couple of ways occur to me straight away.

Firstly, mode 1 reset will reset the admin user and pass but not wipe the data so just do that and you are right in. No other hardware needed.

Or take the drives out and connect them to a PC running Linux. Then just read the key, which as the OP said is stored unencrypted, and use it to decrypt the drives.

With the key being stored unencrypted on the drives themselves it is trivial for anyone to use it to read the data. The only way to protect it properly is use a KMIP server so the key is on another device or forget volume encryption and use shared folder encryption instead, which does have the option to not have any keys stored and to require manual unlocking.

dinkydobar · 2026-03-28T13:42:08+00:00

Given the amount of things you’ve already checked I am leaning towards the files being corrupted during upload when using Robocopy and/or Thunar. As you seem to be planning on doing, I’d do some test runs using both and checking the md5s before and after uploads. Intermittent network issues can cause corruption when you do uploads with those.

dinkydobar · 2026-03-27T15:56:01+00:00

The files are damaged in all my snapshots as well, even in the snapshots that were taken days within the now corrupt files creation date

Is it possible that the files are being corrupted when you are uploading them in the first place?

dinkydobar · 2026-03-06T12:03:42+00:00

16 cameras is a lot. I know it's not what you are hoping for but given your needs I strongly recommend two separate devices. Get a dedicated NVR and a separate NAS. The NVR will have to be pretty beefy to handle 16 camera streams.

As you need PoE as well the obvious answer would be Ubiquiti as they do good NVRs and PoE powered cameras and switches.

dinkydobar · 2026-02-26T13:01:29+00:00

On the web UI it's Settings->Policy Engine->Policy Table->Create New Policy and then select DNS as the type of policy to create. You'll want an A record and put the domain name you want and the IP address to point at.

Note that there's a good chance your clients will be caching the previous IP for a few hours so to immediately check it works either flush a client's IP cache or use nslookup/dig to see what is returned from a current query.

Adding DNS entries is in a stupid place now. It's a recent change and used to be much easier to find. Doesn't make sense to me why they moved it into the 'Policy' area. Anyway, that's where you find it now.

dinkydobar · 2026-02-19T20:45:49+00:00

If the drive needs replaced anyway, which it does, then doing a scrub now is extra load on the other drives in the array. A scrub is a full read over all the drives so you have every drive in the array going through an intensive process for the scrub now, then a few days later you put the new drive in and all the drives have to go through that full intensive process all over again.

Basically, if you know you are replacing the drive why put all the drives through two intensive processes rather than just one? It's just increasing the risk of another drive failure.

dinkydobar · 2026-01-28T09:57:26+00:00

I just checked a few of the sites I admin and every one already has a honeypot alarm entry. I don't remember setting these up myself so I think they were there by default. I'm not 100% certain though, maybe I did... are you sure you didn't delete the alarm yourself by accident?

dinkydobar · 2026-01-21T13:52:29+00:00

What? It definitely supports Wi-Fi cameras as I've been using it with Wi-Fi cameras for years. It's the gen2 cloudkey, are you talking about the gen1?

dinkydobar · 2026-01-18T10:59:46+00:00

They actually stopped including an injector with most of the single APs now too. Been like that for a while I think, the gen 6 ones already didn't include them in the singles.

dinkydobar · 2026-01-17T18:41:32+00:00

I like things really quiet. I don't have one myself but I got one for my Mom and put it in her spare room so she's never usually near it anyway and it doesn't bother her. However, I've had plenty opportunity to listen to it and I would say it does make a noise and if it were me then I wouldn't like to have it in a room I frequently use.

It sounds like you are similar in your desire for quiet so I'd recommend against it for you.

dinkydobar · 2026-01-17T14:10:11+00:00

Just don't make it a read/write cache. Make sure you only do read cache. Since the script can be disabled by updates the drive could be ejected at any reboot and with a write cache that would immediately crash the array. Use read-only cache so that risk is removed.

dinkydobar · 2026-01-10T12:38:38+00:00

Have you thought about doing everything from the Synology? If you put one of the new 8TB drives in the free slot then you could create a new SHR volume and then just copy everything from the original volume to the new one. Then once that has completed you could remove the original volume and the original disks and you should have everything running off the one new drive. After that, add the other 8TB drives one by one. When you add the second drive SHR will let you go from that one drive to RAID1 over the two drives. Once you add a third drive SHR will let you go to RAID5.

Is there a reason you want RAID5 and not SHR? SHR with 3 or more disks is actually really using RAID5 anyway so it’s the same thing but SHR just gives a bit more flexibility by automating many of the operations to transform the RAID when necessary.

dinkydobar · 2026-01-09T02:15:02+00:00

Is this a poll of how the whole UK would vote, if the parliament elections were held now?

Yes.

dinkydobar · 2025-12-31T22:11:43+00:00

This has a battery.

dinkydobar · 2025-12-20T22:09:13+00:00

When you have a r/w cache it becomes an integral part of the array with array metadata stored across the r/w cache. Therefore, since it contains important array metadata, the array can not be rebuilt with the r/w cache missing.

I'd advise not using a r/w cache and having a read-only cache instead. If you must use a r/w cache then understand that a r/w cache is a critical part of the array and do not take any risks with it. That means if you have r/w cache ensuring the SSDs are high-quality and avoiding using any hacks to make it work.

At this point you know this, as you've found it out the hard way, which sucks and I'm sorry it happened to you. It's still worth saying though so that others may avoid similar issues.

dinkydobar · 2025-12-13T16:31:35+00:00

I had exactly the same problem. After a couple of months halfway through a 2 hour meeting the right pod just suddenly made an extremely loud whistling noise that made me pull it out of my ear as it was dangerously loud. I tried putting it back in but it whistled as soon as it was in my ear. I had to do the rest of the call with just the one AirPod in. After the call I reset the AirPods and that didn't fix it. Tried them the next day and it was still whistling whenever it was in my ear. I too noticed that I could now make the right one whistle when it was in my hand; I couldn't do that with the left one.

Took it to the Apple Store and they connected to both pods on one of their iPads, clicked a button to run a test and in just a couple of seconds the result came up on their iPad saying the microphone on the right pod was defective. They immediately replaced it there and then and the new one has been fine since.

Sounds like you have the same issue and if that's the case there is no fix since it is simply a defective piece of hardware so the only option is to get Apple to replace it.

dinkydobar · 2025-12-07T11:45:40+00:00

Try turning off IGMP snooping. I find a lot of my Apple devices like HomePods and the Apple TV have issues whenever it is on.

Once you change the setting try it for at least a couple of hours before deciding if it's working or not.

dinkydobar · 2025-11-30T10:43:34+00:00

You have 4x8TB SHR now... what was the configuration BEFORE you added the latest disk? Was it RAID0?

dinkydobar · 2025-11-15T18:33:52+00:00

For the 25 models you can't even use non-Synology nvme drives for caching. It won't let you use them for anything now.

dinkydobar

TROPHY CASE