Hello!
I use FFS to sync a specific DATA folder on all my machines with each other.
1) daily driver (on semi-vacation now, not relevant to situation) 14” M1 MBP running Sequoia
2) 15” M2 MBA running Sequoia
3) 16” M1 MPB running Sequoia
4) 2018 INTEL MacMini running Monterey and acting as server with FileSharing (AFP and SMB) turned on
5) InfinityBook Pro 14 AMD Gen10 running Tuxedo OS (KDE Plasma 6 Wayland)
6) ThinkPad T490s running Tuxedo OS (KDE Plasma 6 Wayland)
FFS is installed on all of them.
FFS snycs flawlessly between the Mac laptops and the server SMB share. So SMB is working fine, logging on works fine between Macs.
Problem Nr. 1: I just can’t bring FFS on my Linux machines to see the SMB share on the server. I can mount the share in Linux with either Dolphin or SMB4K, even “save” the mounted share to my favorites. I can transfer individual files and folders between the Linux box and the server share. But FFS refuses to “see” it via “Browse” this share, even when mounted.
Problem Nr 2: AI helped me formulate a correct path in the right side field in FFS (left side points to the local DATA folder on the Tuxedo box) that “worked” inasmuch as a “compare” looked at both sides, determined what was needed to be synced and with the clicking on “Synchronize” proceeded to do so. The log listed the files that were synced. Sounds great, eh? Well, when I physically went onto this server share and examined the supposedly synced files, I saw, that the time stamp on the file was the older version, ie it hadn’t been replaced with the newer version, despite the log having stated, that it had been replaced. Opening the file directly in LibreOffice (yes, LibreOffice DOES find the share and can open the file, can even save a change to the server share) showed, that this file with the older file timestamp is indeed the older version of the file. FFS wasn’t “telling the truth” when it claimed to have replaced it with the newer version.
So I’ve had to resort to the late 20th century solution of doing a FFS to an external SSD plugged into my Tuxedo box, then unplug the SSD and plug it into my daily driver 14” M1 and do a sync with this updated SSD, then sync from the M1 to my MacMini FileServer. Works perfectly, but is not the reason one has a file server and is a bit tedious.
Can someone give me a step-by-step how to get FFS to recognize the MacMini Server AND to actually sync the files, not just say it’s done so?
As a help, the server IP is 192.168.0.209
my user profile is cecil
the further path is mydata/DATA
SMB is turned on, so it’ll be with that.
Thanks in advance!
Tuxedo OS vs Monterey SMB shares
- Posts: 4
- Joined: 19 Sep 2026
- Posts: 4
- Joined: 19 Sep 2026
As we say in here in German:
"Kaum macht man's richtig, funktioniert's"
(When you do it correctly, it works)
Well consulted AI again and after about 45 minutes of trying WRONG suggestions, it finally did come up with two paths that worked in SMB4K to mount both the actual DATA share AND it's enclosing folder. This morning during breakfast, I set up a fresh DATA repository on my Monterey server via RustDesk and started a new preset on FFS between my backup Mac and this new rrepository. Inasmuch as it's 95GB of data going over wifi, it's taking about an hour. But I was successful in setting up a new FFS preset on my Tuxedo Linux box - can't wait to try it. IOW - the SMB4K mounted share DID actually appear in the window when I clicked the right side "Browse" button, so could select the new repository as the target. Now will try it when my backup MAc is finished populating the folder on the server.
And THEN will try addressing problem 2 - the timestamp problem.....
"Kaum macht man's richtig, funktioniert's"
(When you do it correctly, it works)
Well consulted AI again and after about 45 minutes of trying WRONG suggestions, it finally did come up with two paths that worked in SMB4K to mount both the actual DATA share AND it's enclosing folder. This morning during breakfast, I set up a fresh DATA repository on my Monterey server via RustDesk and started a new preset on FFS between my backup Mac and this new rrepository. Inasmuch as it's 95GB of data going over wifi, it's taking about an hour. But I was successful in setting up a new FFS preset on my Tuxedo Linux box - can't wait to try it. IOW - the SMB4K mounted share DID actually appear in the window when I clicked the right side "Browse" button, so could select the new repository as the target. Now will try it when my backup MAc is finished populating the folder on the server.
And THEN will try addressing problem 2 - the timestamp problem.....
- Posts: 4
- Joined: 19 Sep 2026
Well, the first pass between my Tuxedo OS box and the new server repository threw up about 75% errors – files it refused to copy. I told FFS to ignore the errors and I’d look at them in the log. I bet these had to do with time-stamp issues. But I’ve seen this before. The crucial step will come in later sync operations. There are 5 LibreOffice files I change multiple times during the day, so I have a good idea what I changed between sync operations, and can check if these are being synced with the older versions being “safety-netted” OR if as before, the logs say they were synced, but they actually weren’t.
For some reason, the sync procedure broke off. When I did the compare again, it showed 5600 files to copy – about 50% of them left for this second time around. At this point, Processed = 221, errors = 1148. Borke off again and compare again said there are 5000 remaining to be synced. I think it’s simply not going to either get any further OR these are the >5000 files that simply can’t be synced. Going to this new folder in Dolphin, the Properties function lists 21,674 files. Going to the local analog folder, Dolphin lists 15,122 files. SO … it looks like this sync procedure has deleted about 6500 files from the local folder. Fortunately, I can restore all that , but … it’s not acceptable.
Came back today and same results as this morning – FFS finds 5000+ files that need to be synced. Looking at the log, some seem to be some kind of temporary files. But others … are just files it say can’t besynced because the file already exists. Isn’t that the point? And checking the share on the server, and my sample files I know I changed, some were synced, some not. Also not acceptable.
For some reason, the sync procedure broke off. When I did the compare again, it showed 5600 files to copy – about 50% of them left for this second time around. At this point, Processed = 221, errors = 1148. Borke off again and compare again said there are 5000 remaining to be synced. I think it’s simply not going to either get any further OR these are the >5000 files that simply can’t be synced. Going to this new folder in Dolphin, the Properties function lists 21,674 files. Going to the local analog folder, Dolphin lists 15,122 files. SO … it looks like this sync procedure has deleted about 6500 files from the local folder. Fortunately, I can restore all that , but … it’s not acceptable.
Came back today and same results as this morning – FFS finds 5000+ files that need to be synced. Looking at the log, some seem to be some kind of temporary files. But others … are just files it say can’t besynced because the file already exists. Isn’t that the point? And checking the share on the server, and my sample files I know I changed, some were synced, some not. Also not acceptable.
- Posts: 4
- Joined: 19 Sep 2026
Reversing the Logic: Reliable Mac-to-Linux File Syncing
As is so often the case with cross-platform computing, the most direct route isn't always the one that works.
File-syncing between a Mac and a Linux box over a local network is notoriously fragile. If you initiate the synchronization from the Linux machine, it will most often fail due to the way Linux and MacOS disagree on file timestamps. However, if we reverse the logic, it works perfectly. Instead of the Linux machine initiating the process, the Mac drives it. We configure the Mac to treat the Linux machine exactly like a home server. The Linux machine only has to "look" and act like a home server to make this happen.
This breakthrough came after months of investigating countless software solutions. For a long time, I used FreeFileSync on all my Macs. It was brilliant for syncing data from each Mac to my Mac home server—it worked every single time. But it simply refused to work properly when driven from the Linux computer (meaning, using FreeFileSync installed on the Linux machine with the Mac server mounted to it).
The only workaround that previously worked was using a physical intermediary: I could attach an external SSD to the Linux machine, use a FreeFileSync preset to sync my main DATA folder to an identical folder on the external SSD, then physically move that external SSD to the Mac and repeat the sync process there. It worked flawlessly, much like how you might handle backups at home using physical drives with Time Machine. But it was manual.
I finally thought of reversing the process entirely and driving it all over the network from the Mac. I turned on File Sharing on the Linux machine, located the main DATA folder I had been syncing via the SSD, and configured SMB (Samba) to share it over the network, restricted only to my user account. Then, I configured FreeFileSync on the Mac to target this Linux network share.
It finally worked. You can sync back and forth perfectly, but the entire process must be initiated from the Mac side, not the Linux side. I can't be sure, but I don't think this is a problem with FFS per se, but rather this basic SMB incompatibility between Apple's version of SMB and Linux' version of SMB.
As is so often the case with cross-platform computing, the most direct route isn't always the one that works.
File-syncing between a Mac and a Linux box over a local network is notoriously fragile. If you initiate the synchronization from the Linux machine, it will most often fail due to the way Linux and MacOS disagree on file timestamps. However, if we reverse the logic, it works perfectly. Instead of the Linux machine initiating the process, the Mac drives it. We configure the Mac to treat the Linux machine exactly like a home server. The Linux machine only has to "look" and act like a home server to make this happen.
This breakthrough came after months of investigating countless software solutions. For a long time, I used FreeFileSync on all my Macs. It was brilliant for syncing data from each Mac to my Mac home server—it worked every single time. But it simply refused to work properly when driven from the Linux computer (meaning, using FreeFileSync installed on the Linux machine with the Mac server mounted to it).
The only workaround that previously worked was using a physical intermediary: I could attach an external SSD to the Linux machine, use a FreeFileSync preset to sync my main DATA folder to an identical folder on the external SSD, then physically move that external SSD to the Mac and repeat the sync process there. It worked flawlessly, much like how you might handle backups at home using physical drives with Time Machine. But it was manual.
I finally thought of reversing the process entirely and driving it all over the network from the Mac. I turned on File Sharing on the Linux machine, located the main DATA folder I had been syncing via the SSD, and configured SMB (Samba) to share it over the network, restricted only to my user account. Then, I configured FreeFileSync on the Mac to target this Linux network share.
It finally worked. You can sync back and forth perfectly, but the entire process must be initiated from the Mac side, not the Linux side. I can't be sure, but I don't think this is a problem with FFS per se, but rather this basic SMB incompatibility between Apple's version of SMB and Linux' version of SMB.