Hi everyone,

A couple of weeks ago, I moved from another Linux based server to Unraid. Since then, I have observed a noticeable increase in corrupt SQLite databases of Docker containers. I never had this problem in the past for many years. But now I see two or three corrupt databases per week?!

Docker (docker.img and appdata) is stored on a mirrored ZFS pool consisting of two SSDs with no file system errors.

I tried to increase the Docker stop timeout to 60 seconds, but this does not seem to help.

I know, that this has been an issue in the past (there are many threads about it) but not lately anymore. Is database corruption still an issue, or am I an exception? Is there anything I can do to prevent this? Or anything else I could try?

Thanks a lot!

Thorsten

unraid-diagnostics-20250819-0715.zip

I would switch the docker stuff to "directory" instead of "image".

Then the files will reside in the normal filesystem and benefit from features list mirroring and so on. Also the cache is "closer to the data" and corruption (which usually is a result of wrongly synced cache contents) is less likely.

(Also backup is much easier this way!)

Edited August 19, 2025Aug 19 by MAM59

Interesting! "image" was the default in Unraid, so I didn't even question it.

Why did Lime Tec decide to use an image? What are the advantages/disadvantages of this approach?

Is it easy/safe to switch to "dir"?

1 hour ago, Tom7320 said:

Why did Lime Tec decide to use an image? What are the advantages/disadvantages of this approach?

Is it easy/safe to switch to "dir"?

No idea what drove them to "image", maybe it is like the always turned on bonding in networking too?

I dont know for sure, but "image" is easier to handle because for the OS it is a single (big) file.

I've once swiched to "dir" because I wanted to be able to access the docker's configs from outside the docker too. For instance for Backup purposes.

And to isolate actions between dockers (if one goes crazy it does not wreck the configs of the others too).

The switch is easy, but it may be always wise to do a backup first in case you need to go back whatever for.

Ok. Thank you!

I did the switch. It was really easy without data loss, without manual configuration. Just stopped the Docker service, switched to "directory", enabled Docker service, marked all apps in Apps -> Previous Apps -> Docker, waited an hour and that was it...

Is there anything else I could do to prevent database corruption? What about the overlayfs? Better to use /mnt/tank instead of /mnt/user?

2 hours ago, Tom7320 said:

Is there anything else I could do to prevent database corruption? What about the overlayfs? Better to use /mnt/tank instead of /mnt/user?

Just wait and see now. Maybe your problem is already gone now?

I dont know about any "overlayfs" and /mnt/tank does not exist in UNRAID as far as I know.

As far as I know is that "overlayfs" is mostly used to allow writing to write protected filesystems. This is not needed on UNRAID, all OS is run from a ramdisk, all changes are lost at reboot.

UNRAID is not Raspian :-)

Sorry! I misunderstood!

/mnt/disk1|2, /mnt/tank are mountpoints of "real" file systems:

root@Unraid:/mnt# mount | grep -e xfs -e zfs
/dev/md1p1 on /mnt/disk1 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md2p1 on /mnt/disk2 type xfs (rw,noatime,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/mnt/tank on /mnt/tank type zfs (rw,relatime,xattr,posixacl,casesensitive)
[...]

/mnt/user is a mountpoint of a "combined", "virtual" fuse file system, I think:

root@Unraid:/mnt# mount | grep user
shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
[...]

So I asked myself whether it would be better to use /mnt/tank/appdata instead of /mnt/user/appdata.

Edited August 19, 2025Aug 19 by Tom7320

3 minutes ago, Tom7320 said:

/mnt/user is a mountpoint of a "combined", "virtual" fuse file system, I think:

not necessarily. UNRAID "sees" if a directory is only on a single disk and automatically sets the attribute "exclusive" for that share.

Check the appdata for this bit.

If set, FUSE is avoided, there will be a direct symbolic link in /mnt/user for that share.

No speed degregation then.

(your "trick" was used on older versions of UNRAID)

Aaaahhhhh. Thx! That is interesting! But it is not enabled by default (I never changed default settings):

Is it advisable to enable this feature? I always feel uncertain if such a feature is not set as default....

you can safely enable exclusive shares / access (the term is quite misleading I think)

you need to turn it on globally:

Afterwards the shares that match the criteria automatically will be converted and show the hook (you can never set it directly for a share)

Edited August 19, 2025Aug 19 by MAM59

Ok. Thanks again! I'll try this evening at home...

It still seems to work perfectly! I will keep observing it further...

What's the recommended Docker storage driver? Overlayfs2 or native? There was a problem with native Docker ZFS storage driver in the past:

https://blog.chlc.cc/p/docker-and-zfs-a-tough-pair/

https://test-dockerrr.readthedocs.io/en/latest/userguide/storagedriver/zfs-driver/

Edited August 20, 2025Aug 20 by Tom7320

1 hour ago, Tom7320 said:

What's the recommended Docker storage driver? Overlayfs2 or native?

Dunno, keep in mind that most of those articles do not apply to UNRAID, its hard to tell what is correct and what not.

UNRAID's ZFS is still under development, some features are still missing.

So just keep cool and take what is available. Don't fiddle around too much, you may run into surprising problems.

I did not even know what settings I had (just looked them up, its "overlayfs2", whatever it is good for).

It works, thats good.

Until yesterday, I didn't even know what a Docker Storage Driver was... 😁😂🫣

https://dev.to/abhay_yt_52a8e72b213be229/understanding-docker-storage-drivers-choosing-the-right-driver-for-your-containers-3m72