Hey there,

I recently wasn't able to perform further Time Machine backups on my Unraid Server so I set a new SMB share up again to see if that would kick it back into gear because this was a relatively newer laptop and I didn't care about losing the old spare bundle image. As it turns out that didn't work either. Anybody able to point me in the right direction?

tower-diagnostics-20260906-1133.zip

The diagnostics show two separate problems.

Samba was still trying to access the old Time Machine share, but its directory under /mnt/user no longer existed. This caused the repeated “No such file or directory” errors.

The replacement share exists and appears to be configured correctly. However, the diagnostics were collected before the Mac tried to use it, so they do not show the new failure.

Remove the old destination from Time Machine and disconnect the old SMB mount. Then connect to the replacement share and select it again. Confirm that Finder can create and delete a small test file on the share before starting another backup.

If it still fails, please provide:

- The exact macOS version

- The complete Time Machine error

- The approximate time of the attempt

- New diagnostics collected immediately afterward

There is also a separate issue. The cache NVMe is repeatedly reporting critical medium read errors at one fixed location. SMART still reports PASSED, but the drive has recorded a media error.

Copy any unique cache data to another device before running a scrub or stress test. I recommend replacing that NVMe. The replacement Time Machine share is stored on disk1, so the NVMe is not currently in its data path.

macOS version: Tahoe 26.6.2

Time Machine error: "Time Machine couldn't complete the backup to "timemachine"

The network backup disk could not be accessed because there was a problem with the network username or password. You may need to re-select the backup disk and enter the correct username and password."
Approximate time of the event: 8:30 AM PST

I was able to confirm that I can make files and folders on my new Time Machine share smb://x.x.x.x/timemachine so it's a little odd to me that it's throwing a username and password error.

I feel like I need a little more information on how to test the NVMe drive if that's ok? I have drives at disk1 disk2 disk3 so could I just temporarily rsync my cache root to one of those drives at like /mnt/disk3/tempcache and then run those tests?

Attached is a new diagnostics .zip I gathered right after a Time Machine backup attempt.

tower-diagnostics-20260907-0829.zip

The replacement share exists, its Time Machine SMB configuration looks correct, and your successful Finder write test confirms that the path is accessible and writable.

However, the share is currently configured as Public, which permits guest access. Finder may therefore be using a guest or previously cached connection while Time Machine is trying different saved credentials.

Please try the following:

1. Create or use a regular Unraid user with a password, do not use root.

2. Change the Time Machine share’s SMB Security setting to Private and give that user Read/Write access.

3. Remove the destination from Time Machine and disconnect existing SMB connections to the server.

4. In macOS Keychain Access, remove saved network-password entries for both the server IP and hostname.

5. Reconnect in Finder using the same SMB address and the named Unraid user, then add that share to Time Machine again.

If it still fails, please note the exact failure time and collect diagnostics after the error appears. The diagnostics you attached do not contain the reported attempt: their syslog stops at 08:26, while the attempt was around 08:30.

Regarding the cache NVMe, the new diagnostics contain nine additional critical-medium read errors at the same LBA. SMART still reports PASSED, but that does not override the repeated device-level read errors. I recommend copying the data and replacing the NVMe rather than relying on a self-test.

Copying /mnt/cache to /mnt/disk3/tempcache is reasonable, provided disk3 is healthy and has sufficient free space. First stop Docker, VM Manager, and anything else writing to cache. Then run:

mkdir -p /mnt/disk3/tempcache

rsync -aHAXS --numeric-ids --info=progress2 /mnt/cache/ /mnt/disk3/tempcache/

Do not add --delete. Check that rsync completes without read errors. Also keep both ends as physical disk/pool paths, do not change one side to /mnt/user/....

Once the copy is safe, you can run an Extended SMART self-test from the cache device’s SMART page if desired, but even a passing result would not change the replacement recommendation. Please do not run a scrub or stress test before protecting the data.

The replacement Time Machine share is on disk1, so the failing cache NVMe is not causing this credentials error.

OK! I was able to get Time Machine to startup again successfully with your steps and recommendations. It seems that for the new share I indeed didn't have it set to secure and my user wasn't set to read / write permissions. I had to remount the share once I had the permissions for my user set correctly for the Time Machine System Preferences to notice the disk again.

After I finish the Time Machine backup and I finish the rsync, is there a good way to take the NVME cache offline in preparation for the replacement? Or should I just shutdown the array for the time being to be safe?

rsync -aHAXS --numeric-ids --info=progress2 /mnt/cache/ /mnt/disk3/tempcache/
  5,273,262,627  18%   61.45MB/s    0:01:21 (xfr#34202, to-chk=130/36047) 
rsync: [sender] read errors mapping "/mnt/cache/appdata/urbackup/urbackup/fileindex/backup_server_files_index.lmdb": Input/output error (5)
 28,424,802,373 100%   84.25MB/s    0:05:21 (xfr#34315, to-chk=130/36047)
rsync: [sender] read errors mapping "/mnt/cache/appdata/urbackup/urbackup/fileindex/backup_server_files_index.lmdb": Input/output error (5)
ERROR: appdata/urbackup/urbackup/fileindex/backup_server_files_index.lmdb failed verification -- update discarded.
 28,424,802,373 100%   84.25MB/s    0:05:21 (xfr#34315, to-chk=0/36047)  
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1356) [sender=3.4.4]

I have the replacement NVMe in hand and I finished the rsync with an error that you see above. I have the array stopped - should I go ahead and proceed and ignore this error or is there something I can do to address it? I was thinking about starting fresh with urbackup anyways as well because I've been having some problems with it backing up lately too.

I ended up installing my new NVMe and formatting it and adding it as a cache drive and all was well. I thought I broke something at first because on the first boot I saw no HDDs - didn't plug in the power connector for the HDDs at first and had to reopen the mini ITX case again, thankfully that power connector is right at the top middle back of my case.

I had to point my Docker vDisk location again to /mnt/cache/system/docker/docker/docker.img after doing the rsync back from my disk3 because for some reason that was reset and I couldn't see my Docker images upon resetting everything.

Thank you for the help and for telling me that disk was failing! This was a lesson learned to not use cheap NVMe(s).