I’m trying to use Backup to backup a folder on one Zimaos server to another Zimaos server. On the first I create shared folder (shows as)
smb://Zimaos.eug.biz/TestBackup
when i LAN mount mount this from the other Zimaserver it shows as
Zimaos.eug.biz however when i pick it, it will not show any contents.
Ive tried to mount it as
Zimaos.eug.biz/TestBackup
or just as
Zimaos.eug.biz
as either a named user or as guest no files ever show up. I get the
“Oops! Something went wrong”… image in the Files app
Am i not understanding the Backup app conceptually or am i just doing something wrong?
I can successfully mount any of the shares i create on my Mac just not from one Zima to another.
I believe you’re very close, and this is usually not a “Backup app” problem, but a ZimaOS-to-ZimaOS SMB mounting limitation / authentication issue inside the Files app.
What I believe is happening
Your share exists (Mac can browse it ), so SMB on Server A is working.
But when you mount it from Server B, Files shows the server but can’t list the share contents, then throws “Oops! Something went wrong”.
I believe this happens when:
the mount is made at the server level (SMB root) but the share isn’t being enumerated, or
the mount succeeds but the share denies listing because of permissions/guest access, or
hostname / DNS resolution is confusing the SMB browser (common when using a domain name inside LAN mounts)
What I suggest (most reliable fix)
1) Use the LAN IP instead of the domain name
On Server B, mount using:
smb://<ServerA_LAN_IP>/TestBackup
Example:
smb://192.168.0.50/TestBackup
I suggest avoiding:
smb://Zimaos.eug.biz/...
Because ZimaOS sometimes struggles with SMB browsing when DNS or routing is involved (even if macOS works fine).
2) Do NOT mount just the server root
Mount the share directly, not:
smb://Zimaos.eug.biz
Instead:
smb://192.168.0.50/TestBackup
Because many SMB servers don’t allow listing shares at root for guest/users, so you get “empty” / error.
3) Use a real user (avoid Guest)
Even if Guest works on Mac, I suggest:
Create a dedicated user like backupuser
Give it explicit permission to TestBackup
Mount using that user
ZimaOS tends to behave better with authenticated SMB mounts.
Quick sanity checks on Server A
In Files > TestBackup > Permissions
confirm the user you’re using has Read/Write
confirm it’s not restricted to “local only” style access
If you want to confirm from SSH (optional but useful)
On Server B run:
ping -c 3 <ServerA_LAN_IP>
Then:
smbclient -L //<ServerA_LAN_IP> -U backupuser
This should list shares. If it errors, it confirms it’s SMB auth / browsing (not Backup app).
Backup app concept (important)
I believe you’re thinking correctly: Backup needs the destination location to be mountable, but the Backup tool itself doesn’t “discover” SMB shares magically, it relies on the mount being visible and readable in the OS.
So yes: conceptually, you’re doing the right thing, the LAN Mount step is what’s failing.
Backup is now working, thank you so much for the response. I had been wondering if Id had it conceptually correct, appreciate confirmation.
It seems that using the LAN ip address was the fix for this issue. I had tried all of the variations of 2 and 3 and none had worked, hence my confusion.
Aside from this, I’ve had relatively little problem. Im actually quite pleased with ZimaOS, I “get” to do IT all day for work and this is really a joy to use at home.
I believe this is a common ZimaOS-to-ZimaOS mount behaviour: using the LAN IP (or local hostname) is usually the most reliable option, because SMB share browsing via domain/DNS discovery can sometimes fail or show empty folders even though the share is valid.
So yes, conceptually you were 100% correct. The key fix was simply mounting via:
//<LAN-IP>/<ShareName>
Thanks for posting the outcome too, it’ll help the next person who hits the same “Oops! Something went wrong” issue in Files.