FFS crashes Mac on sync to Synology NAS

[will-c]

Only owned this Mac for a few months, and using FFS for less time. I back up a collection of data periodically, about weekly. Have a few defined FFS jobs that sync to USB drives. Run fine. When I run FFS to sync these same directories to a Synology NAS on a home network it inevitable crashes the Mac. Have searched forum but nothing similar found. Have three crash logs I've retained to send but don't see a file upload function. Please advise.

[BeerDude]

I'm having the same issue as will-c. I've used FFS on three separate M1 Mac devices to sync media to my server, and FFS locks my systems up when it reaches 25GB of data transferred. To clarify: I'm running FFS on only one device at any given time, not three at the same time. After forcing a shutdown, then a reboot, I run through all the setup again and make sure I have nothing else running for the inevitable crash.

I've tried running the program through Rosetta with no noticeable difference.

[will-c]

I'm not sure its good practice to load the full length of the 3 log reports that macOS produced when FFS crashed the system, the reason message heading the reports (with different numeric values) is:
"panic(cpu 4 caller 0xfffffe002ae45df8): watchdog timeout: no checkins from watchdogd in 90 seconds (3188 total checkins since monitoring last enabled)"

[BeerDude]

Will,

Are you viewing the crash reports through Console? I've only just found out about using it as a viewer and it allowed me to narrow down what my issue might be. I think it was coincidence that I caught the crash at 25GB.

Anyhow, here is what I'm seeing:

Event: disk writes
Action taken: none
Writes: 8589.97 MB of file backed memory dirtied over 631 seconds (13.60 MB per second average), exceeding limit of 99.42 KB per second over 86400 seconds
Writes limit: 8589.93 MB
Limit duration: 86400s
Writes caused: 8589.97 MB
Writes duration: 631s
Duration: 631.46s
Duration Sampled: 630.49s
Steps: 815 ( (10.49 MB/step))

Event: disk writes
Action taken: none
Writes: 2147.58 MB of file backed memory dirtied over 387 seconds (5553.01 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Writes limit: 2147.48 MB
Limit duration: 86400s
Writes caused: 2147.58 MB
Writes duration: 387s
Duration: 386.74s
Duration Sampled: 152.81s
Steps: 204 ( (10.49 MB/step))

[therube]

What version of FFS?

[will-c]

BeerDude: will look into using Console for this & respond.

therube: FFS Version: 11.15 [Donation Edition] - ARM64 - 3/12/21

[RUBEN SALAZAR]

I have the same problem with new M1 Mac Minis, sending data over the 10Gbps network:
- From one raid to other Raid in other M1 Mac Mini or...
- To Google Drive, through the cache folder but finally comparing against the 'cloud' synced data

First I thought it was the hardware (OWC Pro Dock with 10Gbps ethernet) but the same happened with other adapter (Sonnet Thunderbolt 3 to 10Gbps ethernet).

As it was failing through FFS we tested Finder and the same data crashing was moved correctly.

The data transfer speed average can be over 300MBps with peaks of 620MBps (HDDs Raid 5 in both sides).
But at some point it crashes. Curiously the last 3 tests close to the same point after transferring between 720 and 740GB (from 800GB) and a test in between worked fine moving 989GB in less than one hour.
The failed tests were moving and average of 16,500,000 packets although the successful test moved over 21,000,000 packets and 293MBps.

Disks are not sleeping.

I installed last version of FFS and activated Rosetta, and restarted computer.

It is happening in the same environment and different countries with same M1 Big Sur Minis, OWC Raids, and 10Gbps ethernet.

[will-c]

With apologies for delay, I have attached four Crash Report listings, and a Console Diagnostic Report for the fourth crashed run. New to macOS this is all meaningless to me.

[RUBEN SALAZAR]

I found a solution for my Mac Minis M1 with 10Gbps adapter! After reading several articles and forums I tested SAMBA 2 instead SAMBA 3, and it worked. They don't crash anymore and keep high speed (500MB/sec average).

It is supposed to be managed by a file that doesn't exist in the system: nsmb.conf, located in /etc/.. (hidden folder). This file can be safely deleted if not sure about its behavior.

1. The easy way for creating is with TERMINAL. Then add this command:

echo "[default]" | sudo tee -a /etc/nsmb.conf


The file will be created under the admin privileges, so maybe a password will be required.

2. From here you can add new commands in the same way, and restart the computer after finishing:

echo "protocol_vers_map=2" | sudo tee -a /etc/nsmb.conf


echo "mc_prefer_wired=yes" | sudo tee -a /etc/nsmb.conf


echo "mc_on=no" | sudo tee -a /etc/nsmb.conf


(be careful with the " " if using a text editor in the middle cause they could be interpreted as opening / closing quotation marks, “ ” , then the command will not work).

Also, instead the step 2, you could open the basic editor in Terminal typing:

sudo nano /etc/nsmb.conf


Then copying / pasting this below the [default] line, and saving the changes to the file, and restarting the computer:

protocol_vers_map=2
mc_prefer_wired=yes
mc_on=no

Hope it is useful!