Hi,

I recently upgraded to 7.3.0 as of 5 days ago, and found this morning my reverse proxy Docker container was throwing SqliteError: disk I/O error. Tried restarting the container, threw an error of docker: Error response from daemon: error while creating mount source path '/mnt/user/appdata/pangolin/config': mkdir /mnt/user: file exists. Have since then found that all my SMB shares have disappeared.

Reviewing the logs, I'm seeing a lot of `make_connection_snum: canonicalize_connect_path failed for service appdata, path /mnt/user/appdata but for backup as well. I have several shares though and they are all coming back as unreachable in Windows and the Shares tab in Unraid is completely blank.

Attached are diagnostics. I'm currently going through file system checking each disk, but any assistance would be appreciated. Thank you.

notyourunraid-diagnostics-20260521-0908.zip

All drives passed xfs_repair status as no filesystem corruption detected.

I've since rebooted the server and everything appears to have returned to normal.

Will monitor things for now but would be great to know if the diags gave any indication of something failing that I need to address or if this was just a one off blip.

Edited May 21May 21 by idkwatimdoin
Words are hard

1 hour ago, idkwatimdoin said:

All drives passed xfs_repair status as no filesystem corruption detected.

More likely a problem with cache, since /mnt/user0 was mounted, but /mnt/user was not mounted.

31 minutes ago, trurl said:

More likely a problem with cache, since /mnt/user0 was mounted, but /mnt/user was not mounted.

I see. Admittedly I didn't check the caches and only the mechanical drives as that's where I thought the issue stemmed from.

Why the user and user0 paths? User0 seems to contain significantly less than user (I'm assuming that's config related or by design but never gave it much thought until now).

If it were the cache though, should it be expected to see some kind of error or failure in the drive before the shares disappeared from existence?

user0 is the user shares excluding all pools (just the array, in other words). user is the user shares including array and all pools.

I think historically, mover worked by moving cache to user0, so user share settings such as allocation method and split level could be applied when moving to the array.

It is more complicated than that now, but user0 is still created when starting the array because many still want it.

But unless /mnt/user is mounted user shares don't exist. Didn't see exactly where it went away in your diagnostics since it was created when the array started, but it no longer existed when the diagnostics were taken. /mnt/user0 was still there so I assume array access was OK but something not working with pools (cache).

Might be useful scrub cache.

Understood, thanks for the info.

Looks like scrubbing the cache was disabled (seems to have been that way since I set up the server many years ago) so have configured it to run once a month but away from the parity cache check timeframes.

A question on the scrubbing for caches though; while I have redundancy on the cache pool, the drives are different sizes (one is 4TB, the other 2TB for a usable pool of 3TB). I understand making the cache drives the same size would be recommended but not possible for me at the moment.

Will the scrubbing operation run into any problems with different sized drives? Or does it just run off the pool availability size?

2 hours ago, idkwatimdoin said:

Will the scrubbing operation run into any problems with different sized drives?

No, but the usable space is the same as the smaller device.

2 hours ago, JorgeB said:

No, but the usable space is the same as the smaller device.

Interesting. In my use case, these two screenshots seem to report different metrics for usable space (the Main page reports correctly in that 2TB is "usable", but the math on the Dashboard reporting doesn't seem to be mathing:

Dashboard:

Main:

The used/free on main will be correct, cpacity is incorrectly reported in this case, this is a btrfs issue.

There have been known issues with BTRFS space reporting for a long time when you have an odd number of drives that are of mixed sizes. I suspect that this is just a manifestation of that. I believe that the Used space is reliable, but the others are not. As far as I know this needs to be fixed within the BTRFS driver level, but is obviously not trivial issue or would have happened a long time ago.

For mixed sizes of btrfs drives, single profile would give you the total capacity, but of course, you wouldn't

9 hours ago, idkwatimdoin said:

have redundancy on the cache pool

No problems, thank you all for your help.

So far so good. I will keep in mind regarding the cache drives and (at some point when pricing isn't through the roof) replace the lower capacity cache drive with a like size of the existing one.

FWIW, the scrub completed on my cache pool overnight and no system errors were reported there either, so... it's a double-edged sword at this point (great there's no errors, but unsettling that there's no clear reason as to why this happened in the first place).

I'll raise a new topic if the issue recurs and troubleshooting steps here haven't helped.

Thanks again!

Edited May 22May 22 by idkwatimdoin
Words really are hard :|