Fetching Backup Sources Errors out

Been running a weekly backup to a local SMB share. I do have links to SMB shares to other servers over a VPN which are up and responding (though I never use them and should remove)
Anyway, when trying to Create a Backup or for testing purposes Restore a backup,
The system spins for a while with:
Fetching Backup Sources
Then eventually displays:
[Object, Object]

Version: 0.3.5.~1
Git Hash: 39de098461833e4c56bd3509644ddf7f1a0fc4ca

Kernel Log that seems relevant:

2024-02-29T09:41:32-06:00  CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
2024-02-29T09:41:32-06:00  CIFS: Attempting to mount \\\data
2024-02-29T09:41:33-06:00  F2FS-fs (mmcblk0p3): Magic Mismatch, valid(0xf2f52010) - read(0x1e25468c)
2024-02-29T09:41:33-06:00  F2FS-fs (mmcblk0p3): Can't find valid F2FS filesystem in 1th superblock
2024-02-29T09:41:33-06:00  F2FS-fs (mmcblk0p3): Magic Mismatch, valid(0xf2f52010) - read(0x7cb96442)
2024-02-29T09:41:33-06:00  F2FS-fs (mmcblk0p3): Can't find valid F2FS filesystem in 2th superblock
2024-02-29T09:41:33-06:00  CIFS: Attempting to mount \\\start9backup
2024-02-29T09:48:03-06:00  brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
2024-02-29T09:54:21-06:00  INFO: task mount.cifs:44167 blocked for more than 120 seconds.
2024-02-29T09:54:21-06:00  Tainted: G C 6.1.21-v8+ #1642
2024-02-29T09:54:21-06:00  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2024-02-29T09:54:21-06:00  task:mount.cifs state:D stack:0 pid:44167 ppid:44166 flags:0x00000004
2024-02-29T09:54:21-06:00  Call trace:
2024-02-29T09:54:21-06:00  __switch_to+0xf8/0x1e0
2024-02-29T09:54:21-06:00  __schedule+0x2a8/0x830
2024-02-29T09:54:21-06:00  schedule+0x60/0x100
2024-02-29T09:54:21-06:00  schedule_preempt_disabled+0x20/0x38
2024-02-29T09:54:21-06:00  __mutex_lock.isra.17+0x3e4/0xa78
2024-02-29T09:54:21-06:00  __mutex_lock_slowpath+0x1c/0x28
2024-02-29T09:54:21-06:00  mutex_lock+0x3c/0x68
2024-02-29T09:54:21-06:00  smb3_get_tree+0xf0/0x260 [cifs]
2024-02-29T09:54:21-06:00  vfs_get_tree+0x30/0xf8
2024-02-29T09:54:21-06:00  path_mount+0x670/0x978
2024-02-29T09:54:21-06:00  do_mount+0xa0/0xb8
2024-02-29T09:54:21-06:00  __arm64_sys_mount+0x17c/0x268
2024-02-29T09:54:21-06:00  invoke_syscall+0x4c/0x110
2024-02-29T09:54:21-06:00  el0_svc_common.constprop.3+0xfc/0x120
2024-02-29T09:54:21-06:00  do_el0_svc+0x34/0xd0
2024-02-29T09:54:21-06:00  el0_svc+0x30/0x88
2024-02-29T09:54:21-06:00  el0t_64_sync_handler+0x98/0xc0
2024-02-29T09:54:21-06:00  el0t_64_sync+0x18c/0x190
2024-02-29T09:54:50-06:00  brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
2024-02-29T09:56:21-06:00  INFO: task mount.cifs:44167 blocked for more than 241 seconds.
2024-02-29T09:56:21-06:00  Tainted: G C 6.1.21-v8+ #1642
2024-02-29T09:56:21-06:00  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2024-02-29T09:56:21-06:00  task:mount.cifs state:D stack:0 pid:44167 ppid:44166 flags:0x00000004
2024-02-29T09:56:22-06:00  Call trace:
2024-02-29T09:56:22-06:00  __switch_to+0xf8/0x1e0
2024-02-29T09:56:22-06:00  __schedule+0x2a8/0x830
2024-02-29T09:56:22-06:00  schedule+0x60/0x100
2024-02-29T09:56:22-06:00  schedule_preempt_disabled+0x20/0x38
2024-02-29T09:56:22-06:00  __mutex_lock.isra.17+0x3e4/0xa78
2024-02-29T09:56:22-06:00  __mutex_lock_slowpath+0x1c/0x28
2024-02-29T09:56:22-06:00  mutex_lock+0x3c/0x68
2024-02-29T09:56:22-06:00  smb3_get_tree+0xf0/0x260 [cifs]
2024-02-29T09:56:22-06:00  vfs_get_tree+0x30/0xf8
2024-02-29T09:56:22-06:00  path_mount+0x670/0x978
2024-02-29T09:56:22-06:00  do_mount+0xa0/0xb8
2024-02-29T09:56:22-06:00  __arm64_sys_mount+0x17c/0x268
2024-02-29T09:56:22-06:00  invoke_syscall+0x4c/0x110
2024-02-29T09:56:22-06:00  el0_svc_common.constprop.3+0xfc/0x120
2024-02-29T09:56:22-06:00  do_el0_svc+0x34/0xd0
2024-02-29T09:56:22-06:00  el0_svc+0x30/0x88
2024-02-29T09:56:22-06:00  el0t_64_sync_handler+0x98/0xc0
2024-02-29T09:56:22-06:00  el0t_64_sync+0x18c/0x190
2024-02-29T09:58:22-06:00  INFO: task mount.cifs:44167 blocked for more than 362 seconds.
2024-02-29T09:58:22-06:00  Tainted: G C 6.1.21-v8+ #1642
2024-02-29T09:58:22-06:00  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2024-02-29T09:58:22-06:00  task:mount.cifs state:D stack:0 pid:44167 ppid:1 flags:0x00000004
2024-02-29T09:58:22-06:00  Call trace:
2024-02-29T09:58:22-06:00  __switch_to+0xf8/0x1e0
2024-02-29T09:58:22-06:00  __schedule+0x2a8/0x830
2024-02-29T09:58:22-06:00  schedule+0x60/0x100
2024-02-29T09:58:22-06:00  schedule_preempt_disabled+0x20/0x38
2024-02-29T09:58:22-06:00  __mutex_lock.isra.17+0x3e4/0xa78
2024-02-29T09:58:22-06:00  __mutex_lock_slowpath+0x1c/0x28
2024-02-29T09:58:22-06:00  mutex_lock+0x3c/0x68
2024-02-29T09:58:22-06:00  smb3_get_tree+0xf0/0x260 [cifs]
2024-02-29T09:58:22-06:00  vfs_get_tree+0x30/0xf8
2024-02-29T09:58:22-06:00  path_mount+0x670/0x978
2024-02-29T09:58:22-06:00  do_mount+0xa0/0xb8
2024-02-29T09:58:22-06:00  __arm64_sys_mount+0x17c/0x268
2024-02-29T09:58:22-06:00  invoke_syscall+0x4c/0x110
2024-02-29T09:58:22-06:00  el0_svc_common.constprop.3+0xfc/0x120
2024-02-29T09:58:22-06:00  do_el0_svc+0x34/0xd0
2024-02-29T09:58:22-06:00  el0_svc+0x30/0x88
2024-02-29T09:58:22-06:00  el0t_64_sync_handler+0x98/0xc0
2024-02-29T09:58:22-06:00  el0t_64_sync+0x18c/0x190
2024-02-29T10:00:23-06:00  INFO: task mount.cifs:44167 blocked for more than 483 seconds.
2024-02-29T10:00:23-06:00  Tainted: G C 6.1.21-v8+ #1642
2024-02-29T10:00:23-06:00  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Can you give more details about your OS, setup, etc? Have you tried to wipe and re-add the share?

The Start9 Host is a raspberry pi 4
The SMB target is a local SMB 3 linux box.
2 Other backup shares are known to the Start9 box but not used. However, they are pingable. I only used the remote smb share once, but backing up over a VPN was too slow.

The local share was working just fine for several backup cycles. Verified they are up and pingable. Tested from other machines and I Can see the previous embassy backups.

I have not wiped the share, I did unplug start9 from the network to see if it would just time out with no network and let me wipe the current backup destinations that way. No luck.

Hi entropywrench,

Did you follow this guide for your specific distro?


For now I would ignore the video on the Ubuntu page. I know it’s not exactly right but I’m pretty confident the text steps below it are correct.

What is the error in the StartOS UI when you go to make this backup?

I click either Create a Backup or Restore from backup
It spins for about 120-180 seconds with “Fetching Backup Targets”
The error returned is [Object, Object]

No other returned in the Gui, the above code is taken from the Kernel Logs

Did you follow the guide for your specific distro?

It seems like the share has been created with incompatible settings.

Yup I did follow the guide, the CIFS share isn’t likely to be the issue. I made several backups without an issue to the same share previous to the error.
In trouble shooting, I’ve disabled the CIFS shares from all the targets set, isolated the start9 device, and still get the same [Object,Object] return.

At this point I’m trying to figure out how to delete the current backup targets out of start9 and start over with backups

You can just delete (or rename) the EmbassyBackups folder on the target

Did that. Disabled SMFS and tried quite a few things.
Any idea how I delete the reference to the backups on the start9 server?


I attached a screen shot of the “error” get on the console when clicking either Create Backup or Restore

Can you open up your Tools → Browser Tools → Web Developer Tools and take a look at the consle and network tabs to determine if you are connected properly to the server?

So, was on a trip for a week, sometime round last tuesday Start 9 seems to have crashed. When I returned I found a read only file system error on the monitor. A hard reboot later, things synced back, ran the lnBits update.
Tested the backup and it worked just fine, no delay, no errors as indicated above.

I wouldn’t call my issue fixed, just not manifesting at the moment.

I should note the many many other reboots I did in trying to fix this error did not clear it.
Wish I had the error state logs from previous in the week, but doesn’t appear we do.

Good luck out there all and thanks for the suggestions.