Sequoia Time Machine Synology NAS keeps disconnecting

Update: No. 15.0.1 did not solve the problem. The problem re-occurred today.

I installed the recommended Synology beta for SMB and my backup continued to fail. The only workaround I've found to work consistently is to turn the firewall off.

Simply go to System preferences, Open the Network item and in Firewall, toggle it to off, and your backups will work. Of course, it's not ideal if that's the only firewall protecting your machine.

I'm running 15.0.1 with firewall turned on, but my TM backup is still failing, if you turned it off, it will work, but not ideal. Anyone figured out how to get it back working with firewall on?

As disabling Apple's firewall seems to fix the issue, this is clearly not a Synology problem to fix.

Apple did some changes to the firewall settings that are causing the problem.

After additional days retrying backups, only way to get them succeed is disabling the Firewall

Still on Sonoma but recently had this issue - 3 different laptops all kept giving same failure to Synology NAS Time Machine backup. Eventually just had to delete that TM setup, start as new and works on all now.

Don't bother, had it since macOS 12 in combination with DSM6.x and today with macOS 15 in combination with a brand new DS923 running DSM 7.x same issue. Finder loses connection with Synology NAS (and also TM). When will Apple crushes this bug finally? In version 20? Djeezzz.

spoona wrote:

Problem with Synology is back. After working fine for one day. It doesn't matter whether MacOS firewall and Objective-See apps are disabled, Time Machine cannot connect to the NAS, although Finder has no problem.

All of the add-on security apps — all of the add-ons — removed per vendors’ instructions, restarted, and tested again?

This then tested with current DSM on the Synology?

If so, let Synology know, if they don’t already.

Thanks - just checked and it was 'On' on my iMac Pro.

I've flagged the issue to Synology and their automated response suggested clearing all the SMB caches on the Synology Control Panel. But that hasn't fixed it, I've told them this hasn't worked and will see if they send a more detailed response later.

Just wondering - OP and myself are both running Sequoia on Intel processors and getting failures. My M2 MBA is backing up to the same Synology without issues.

Is anyone getting this fault on Apple processors?

Sorry to get peoples' hopes up. My iMac failed to back up this afternoon when I was away and gave the same error about the Synology being disconnected.

So the 'fix' doesn't do anything. Don't waste your time if you haven't started.

Synology have asked me to provide them with a log of the failure so, just as soon as the next backup fails I will share the log information with them and with Apple.

Back to my SanDisk SSD for backups!

I am afraid the problem is on Apple's side.

I have a Synology DS218+ at home, and I have this issue with my MacBook Air recently updated to Sequoia.

I have never had any problems with a Network Time Machine backup (I have three going at the moment). I also don't have Synology anything. It sounds to me that it is on Synology's side.

While checking on different forums, I find someone suggesting to issue the following command in terminal:

log show --info --style compact --predicate '(subsystem == "com.apple.TimeMachine") && (eventMessage like[cd] "Failed * acquire device lock assertion*")' --last 24h

after few seconds, I got the following:

Timestamp Ty Process[PID:TID]

2024-09-29 18:02:52.849 E backupd[54103:292ab9] [com.apple.TimeMachine:FileProtection] Failed to acquire device lock assertion for '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/iMac-M1/2024-09-29-171018/Data/Users/donato/Library/Containers/com.apple.findmy.FindMyWidgetPeople/Data/SystemData/com.apple.chrono/timelines/com.apple.findmy.FindMyWidgetPeople/systemSmall---2695494529729235827----164.00w--164.00h--20.00r--0f--0.00t-0.00l-0.00b0.00t.chrono-timeline' (assertion state: <dropped>), error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"

2024-09-29 18:06:23.246 E backupd[54103:292ab9] [com.apple.TimeMachine:FileProtection] Failed to acquire device lock assertion for '/Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/iMac-M1/2024-09-29-171018/Data/Users/donato/Library/Containers/com.apple.findmy.FindMyWidgetItems/Data/SystemData/com.apple.chrono/timelines/com.apple.findmy.FindMyWidgetItems/systemSmall---3453820889416213992----164.00w--164.00h--20.00r--0f--0.00t-0.00l-0.00b0.00t.chrono-timeline' (assertion state: <dropped>), error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"

There is an issue, "Operation not permitted", with FindMyWidget?

I get the same error on both my macs on Sequoia, an iMacM1 and a MacBookAirM2.

I closed the FindMy Widget on both macs. Let see what happens...

PS: someone else reports that booting into safe mode and then back fixes the problem. Will try this one too...

I encountered the same issue on a 2023 M3 Pro MacBook Pro, typically after computer waking up from sleep. My MBP is connected to the same subnet via both Wi-Fi and a Thunderbolt Ethernet dongle. The backup target is in another VLAN (there is an OPNsense FreeBSD firewall doing L3 routing in between). The TM target is discovered using mDNS (which is repeated by the firewall cross VLANs using mDNS repeater). The Synology is a DS220j running latest DSM.

When the problem occur, the Synology's Resource Manager shows two concurrent connection from my wired IP address to the TM share. I have to kill the older one for TM to work again. This is the workaround I used anytime TM stopped working because of this.

The problem started occurring after upgrading my MBP to 15.0 few weeks ago. I tried eliminating few other probabilities including 1) performance issue with the NAS; 2) L3 firewall state tracking with the pf on my OPNsense firewall when doing inter-VLAN routing and persist idle long connection; 3) concurrent Wi-Fi and wired connection. I come into conclusion that macOS is the most probable one to be blamed.

I have upgraded to 15.0.1 last night and it seems I did not encounter the issue again after waking up the computer this morning. Will continue monitoring the issue.