VlarpNL

It works flawless in my setup now. I added my "non-standard" appdata path and it now just shows the paths that really should be removed.

Then use it? It still works. In the mean time it's nice that someone else is picking up development of a newer version.

Is it possible to add support for non standard paths? Eg. when Docker containers are not using /mnt/user/appdata/. I have some Docker containers that mount on /mnt/fcache/appdata/ to remove some overhead from the /mnt/user mount. What happens now is that the plugin finds all live containers that use these mounts because in the config of the container it's referencing /mnt/fcache/appdata/ instead of /mnt/user/appdata/. Maybe this can be solved by adding an option to add all your appdata paths? The appdata backup plugin does that by adding a source selector: Thanks!

I'm trying to configure my Unifi Controller, I created an API key, entered it in the config, but when I test the Connection it fails: The log reports back this error: INFO: 192.168.1.xx:63869 - "POST /api/config/unifi/test HTTP/1.1" 422 Unprocessable Entity Not sure if I'm doing anything wrong? I'm on Unifi OS 5.0.12 (and Network 10.1.85). Edit: Wait up, I just noticed that the error actually comes from my own PC's IP, not the gateway. I should probably check some more. Edit 2: I literally get that same error from any other machine in my network that I try to test this on. So the log just shows that same error with the IP address of the machine that I use to set the configuration for the UNIFI Toolkit. Edit 3: It's probably not issue with your template, there's an open issue on the Github of unifi-toolkit: https://github.com/Crosstalk-Solutions/unifi-toolkit/issues/55

Thanks for the update! Just tested and it seems to work correctly now! Great work! [2026-01-14 09:48:40] ================================================== [2026-01-14 09:48:40] Plex DBRepair – Native Docker [2026-01-14 09:48:40] ================================================== [2026-01-14 09:48:40] Mode : automatic [2026-01-14 09:48:40] Plex Root : /config/Library/Application Support/Plex Media Server [2026-01-14 09:48:40] Databases : /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases [2026-01-14 09:48:40] SQLite : /usr/lib/plexmediaserver/Plex SQLite (plex) [2026-01-14 09:48:40] Backups Enabled : true [2026-01-14 09:48:40] Restore Last Backup : false [2026-01-14 09:48:40] ================================================== [2026-01-14 09:48:40] Stopping Plex containers (match: Plex-Media-Server) [2026-01-14 09:48:40] ================================================== [2026-01-14 09:48:40] Skipping excluded container: dbrepair [2026-01-14 09:48:40] Stopping Plex container: Plex-Media-Server (d2c15ce7fe52) [2026-01-14 09:48:47] ================================================== [2026-01-14 09:48:47] Automatic (check → vacuum → reindex) [2026-01-14 09:48:47] ================================================== [2026-01-14 09:48:47] ================================================== [2026-01-14 09:48:47] Backup databases [2026-01-14 09:48:47] ================================================== [2026-01-14 09:48:47] Backup : com.plexapp.plugins.library.db [2026-01-14 09:48:47] Backup : com.plexapp.plugins.library.blobs.db [2026-01-14 09:48:47] Backup dir: /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/dbrepair-backups/2026-01-14_09-48-40 (2 file(s)) [2026-01-14 09:48:47] Check : com.plexapp.plugins.library.db ok [2026-01-14 09:48:50] Check : com.plexapp.plugins.library.blobs.db ok [2026-01-14 09:48:52] Vacuum : com.plexapp.plugins.library.db [2026-01-14 09:48:54] Vacuum : com.plexapp.plugins.library.blobs.db [2026-01-14 09:48:56] Reindex : com.plexapp.plugins.library.db [2026-01-14 09:48:58] Reindex : com.plexapp.plugins.library.blobs.db [2026-01-14 09:48:58] ================================================== [2026-01-14 09:48:58] DBRepair completed [2026-01-14 09:48:58] Log : /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/dbrepair-docker-2026-01-14_09-48-40.log [2026-01-14 09:48:58] Backups : /config/Library/Application Support/Plex Media Server/Plug-in Support/Databases/dbrepair-backups [2026-01-14 09:48:58] ================================================== [2026-01-14 09:48:58] ================================================== [2026-01-14 09:48:58] Restarting Plex containers [2026-01-14 09:48:58] ================================================== [2026-01-14 09:48:59] Started: d2c15ce7fe52 ** Press ANY KEY to close this window **

Thanks! I'll gladly test if it works.

I tried changing permissions using chmod to 777 for the DB files, but same thing. Ran the container with the "automatic" option. However I don't want to mess around too much with chown and chmod on the DB files as don't want to break Plex. Just checked and somehow this container creates the log and backup files as root? I thought generally speaking Docker containers on Unraid should all run using the nobody:users permission/owner, right? I'm not sure how it works exactly though, I'm hardly a Linux/Docker expert 😅. So I do appreciate the effort you're putting in. root@XXXX:/mnt/fcache/appdata/Plex-Media-Server/Library/Application Support/Plex Media Server/Plug-in Support/Databases# ls -lh total 529M -rw-r--r-- 1 nobody users 348M Jan 13 20:23 com.plexapp.plugins.library.blobs.db -rw-r--r-- 1 nobody users 32K Jan 13 20:30 com.plexapp.plugins.library.blobs.db-shm -rw-r--r-- 1 nobody users 0 Jan 13 20:30 com.plexapp.plugins.library.blobs.db-wal -rw-r--r-- 1 nobody users 180M Jan 13 20:30 com.plexapp.plugins.library.db -rw-r--r-- 1 nobody users 32K Jan 13 20:31 com.plexapp.plugins.library.db-shm -rw-r--r-- 1 nobody users 532K Jan 13 20:31 com.plexapp.plugins.library.db-wal drwxr-xr-x 1 root root 38 Jan 13 20:30 dbrepair-backups/ -rw-r--r-- 1 root root 1.4K Jan 13 20:30 dbrepair-docker-2026-01-13_20-30-23.log

By the way, could it be a permission/rights issue? Permissions of the DB files is 644. Is that correct? root@XXXX:/mnt/fcache/appdata/Plex-Media-Server/Library/Application Support/Plex Media Server/Plug-in Support/Databases# ls -lh total 529M -rw-r--r-- 1 nobody users 348M Jan 13 15:59 com.plexapp.plugins.library.blobs.db -rw-r--r-- 1 nobody users 32K Jan 13 16:04 com.plexapp.plugins.library.blobs.db-shm -rw-r--r-- 1 nobody users 0 Jan 13 16:04 com.plexapp.plugins.library.blobs.db-wal -rw-r--r-- 1 nobody users 180M Jan 13 16:04 com.plexapp.plugins.library.db -rw-r--r-- 1 nobody users 32K Jan 13 16:09 com.plexapp.plugins.library.db-shm -rw-r--r-- 1 nobody users 769K Jan 13 16:09 com.plexapp.plugins.library.db-wal

I tried all the DBREPAIR_MODE listed in your first post. All of them result in the same: Plex container is stopped, backup gets created, Plex is restarted. The repair script doesn't seem to run. The only difference was with the 'check' DBREPAIR_MODE this outputs an extra error: Error: in prepare, no such collation sequence: icu_root. Tried this twice and same error occurs. In this case also no backups are created. [2026-01-13 16:04:00] ================================================== [2026-01-13 16:04:00] Plex DBRepair – Native Docker [2026-01-13 16:04:00] ================================================== [2026-01-13 16:04:00] Mode : check [2026-01-13 16:04:00] Plex Root : /plexmediaserver/Library/Application Support/Plex Media Server [2026-01-13 16:04:00] Databases : /plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases [2026-01-13 16:04:00] SQLite : /usr/bin/sqlite3 [2026-01-13 16:04:00] Backup Dir : /plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/dbrepair-backups/2026-01-13_16-04-00 [2026-01-13 16:04:00] Exclude Names : dbrepair,plex-dbrepair [2026-01-13 16:04:00] Exclude Image Regex : plex-dbrepair [2026-01-13 16:04:00] ================================================== [2026-01-13 16:04:00] Scanning for Plex containers to stop (match: Plex-Media-Server) [2026-01-13 16:04:00] Skipping (excluded name): dbrepair [2026-01-13 16:04:00] Stopping Plex container: Plex-Media-Server (d2c15ce7fe52) image=plexinc/pms-docker:beta [2026-01-13 16:04:06] Check: com.plexapp.plugins.library.db Error: in prepare, no such collation sequence: icu_root [2026-01-13 16:04:06] Restarting Plex containers that were stopped... [2026-01-13 16:04:07] Started: d2c15ce7fe52 ** Press ANY KEY to close this window **

Thanks for the update! Just tested it, but somehow it looks like it doesn't run the actual DBRepair.sh script? When I start the dbrepair container it does stop my Plex Media Server container and it makes a backup of the SQLite databases, but that seems to be all it's doing before starting the PMS container again (there is no DBRepair.log for example). I'm using the official Docker container by Plex Inc. (plexinc/pms-docker:beta). Let me know if I can help you figure out what goes wrong here. Below some data I collected. I also tried running dbrepair container privileged, but that made no difference. These are the settings I'm using: The contents of the Databases directory: Contents of the dbrepair-backups folder (these all contain proper copies of teh SQLite databases): Log output of the dbrepair container: [2026-01-13 09:18:37] ================================================== [2026-01-13 09:18:37] Plex DBRepair – Native Docker [2026-01-13 09:18:37] ================================================== [2026-01-13 09:18:37] Mode : automatic [2026-01-13 09:18:37] Plex Root : /plexmediaserver/Library/Application Support/Plex Media Server [2026-01-13 09:18:37] Databases : /plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases [2026-01-13 09:18:37] SQLite : /usr/bin/sqlite3 [2026-01-13 09:18:37] Backup Dir : /plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/dbrepair-backups/2026-01-13_09-18-37 [2026-01-13 09:18:37] Exclude Names : dbrepair,plex-dbrepair [2026-01-13 09:18:37] Exclude Image Regex : plex-dbrepair [2026-01-13 09:18:37] ================================================== [2026-01-13 09:18:37] Scanning for Plex containers to stop (match: Plex-Media-Server) [2026-01-13 09:18:37] Skipping (excluded name): dbrepair [2026-01-13 09:18:37] Stopping Plex container: Plex-Media-Server (d2c15ce7fe52) image=plexinc/pms-docker:beta [2026-01-13 09:18:44] Creating backups... [2026-01-13 09:18:44] Restarting Plex containers that were stopped... [2026-01-13 09:18:44] Started: d2c15ce7fe52 ** Press ANY KEY to close this window **

It seems this Docker is not working correctly. I ran the DBRepair script directly in my Plex Media Server container, following https://github.com/ChuckPa/DBRepair?tab=readme-ov-file#installation inside the container's console. The Check option finishes in seconds. Automatic finishes in less than a minute. The script outputs different details than the version in the Docker container. It would be helpful of the output of DBRepair.sh is also visible in this Docker's logfile. That way it might be possible to see what the problem is. I'm assuming it to be an issue with permissions, but since I can't see the raw output of the DBRepair.sh script I'm not 100% sure.

Same here, just running it now. It's been working for over 20 minutes. But the heartbeat is still updating and I see the script using CPU, so I guess it should be fine?

You can click on the folder name (so you see the settings for the folder and the Dockers added to it) and then drag items to other positions? Seems to work when I try it.

Just switch over to the new version. Very happy it's working again. Thanks @VladoPortos!

I did the same thing. But would definitely like it better when there is 0% option in the Global settings for the plugin.

Thanks for the help. It's gone now, I'll monitor if my system is stable now.

Yeah, I was just going through the logs and didn't think to post the full diagnostics, sorry about that. I had the corefreq plugin installed but I removed it. I'm not completely sure if I removed it before the hang or not. I attached the diagnostics but I just checked and it doesn't seem to contain the moment the hang/crash occured. The only thing that contains that is the log saved by my syslog server. I attached that log as well. vlarpserv-diagnostics-20210811-2054.zip Syslog.txt

Hi guys, My Unraid server hangs every few days. I grabbed the below info from syslog showing the trace. I'm not a Linux guru at all so I have no clue what to look at that shows what happened. Any insights would be appreciated. Thanks! 2021-08-11 10:20:23 Kernel.Error 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: 2021-08-11 10:20:23 Kernel.Error 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: rcu: 1-...0: (5 ticks this GP) idle=586/1/0x4000000000000000 softirq=41567442/41567443 fqs=14976 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: (detected by 0, t=60002 jiffies, g=65020929, q=2400) 2021-08-11 10:20:23 Kernel.Info 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Sending NMI from CPU 0 to CPUs 1: 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: NMI backtrace for cpu 1 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: CPU: 1 PID: 17600 Comm: Tdarr_Node Tainted: P O 5.10.28-Unraid #1 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Hardware name: HPE ProLiant MicroServer Gen10/ProLiant MicroServer Gen10, BIOS 5.12 06/26/2018 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x79/0x18a 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Code: c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 74 0c 0f ba e0 08 72 1a c6 47 01 00 eb 14 85 c0 74 0a 8b 07 84 c0 74 04 f3 90 <eb> f6 66 c7 07 01 00 c3 48 c7 c0 00 30 02 00 65 48 03 05 f0 8e f8 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RSP: 0018:ffffc9000015ce68 EFLAGS: 00000002 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RAX: 0000000000040101 RBX: ffffc9000015ce90 RCX: 0000000000000000 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881000a9d40 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RBP: 8000015d00006c0d R08: ffffffff82013888 R09: ffffffff82013580 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R10: 0001370722c9b2fd R11: 0000972caf555a8f R12: 00008044bfcf4231 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R13: 0000000000000001 R14: 000000003b9aca00 R15: ffff8887ef49f040 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: FS: 000014f8eece3780(0000) GS:ffff8887ef480000(0000) knlGS:0000000000000000 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: CR2: 000017d29dc3b000 CR3: 0000000217226000 CR4: 00000000001506e0 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Call Trace: 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: <IRQ> 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: queued_spin_lock_slowpath+0x7/0xa 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: nr_blockdev_pages+0x13/0x64 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: si_meminfo+0x3a/0x57 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Sys_MemInfo+0x20/0x9b [corefreqk] 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? _raw_spin_unlock_irqrestore+0xd/0xe 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? try_to_wake_up+0x1b0/0x1e5 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? timekeeping_get_ns+0x19/0x2f 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? Sys_DumpTask+0xe9/0xf1 [corefreqk] 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Cycle_AMD_Family_15h+0x265/0x3e6 [corefreqk] 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: __hrtimer_run_queues+0xb7/0x10b 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? Core_AMD_Family_15h_Temp+0x8b/0x8b [corefreqk] 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: hrtimer_interrupt+0x8d/0x15b 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: __sysvec_apic_timer_interrupt+0x5d/0x68 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: asm_call_irq_on_stack+0x12/0x20 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: </IRQ> 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: sysvec_apic_timer_interrupt+0x71/0x95 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RIP: 0010:nr_blockdev_pages+0x4c/0x64 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Code: 00 00 48 8d 97 48 05 00 00 48 2d 10 01 00 00 48 8d 88 10 01 00 00 48 39 d1 74 17 48 8b 48 30 48 8b 80 10 01 00 00 4c 03 41 58 <48> 2d 10 01 00 00 eb dd 48 81 c7 40 05 00 00 e8 fa de ff ff 4c 89 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RSP: 0018:ffffc90001adfcd8 EFLAGS: 00000202 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RAX: ffff888100444dc8 RBX: ffffc90001adfd20 RCX: ffff888100445128 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RDX: ffff8881000a9d48 RSI: 0000000000000001 RDI: ffff8881000a9800 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RBP: ffff888100a8e4b0 R08: 000000000000005b R09: ffff8883f6308400 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R10: 0000000000001008 R11: 0000000000000001 R12: ffffc90001adfe80 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R13: 0000000000000001 R14: ffff888100a8e4d8 R15: ffff888100a8e4b0 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? nr_blockdev_pages+0x13/0x64 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: si_meminfo+0x3a/0x57 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: meminfo_proc_show+0x33/0x540 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? __mod_memcg_state+0x5/0x9d 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? mod_objcg_state+0x2a/0x30 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? slab_post_alloc_hook+0x10c/0x14a 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ? __kmalloc_node+0x144/0x16d 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: seq_read_iter+0x15e/0x339 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: proc_reg_read_iter+0x4d/0x5f 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: new_sync_read+0x77/0xaa 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: vfs_read+0xbe/0xff 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: ksys_read+0x71/0xba 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: do_syscall_64+0x5d/0x6a 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RIP: 0033:0x14f8ee95636c 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 89 fc ff ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 48 89 44 24 08 e8 bf fc ff ff 48 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RSP: 002b:00007ffc2983d500 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RAX: ffffffffffffffda RBX: 0000000000000017 RCX: 000014f8ee95636c 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RDX: 0000000000000fff RSI: 00007ffc2983d540 RDI: 0000000000000017 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: RBP: 00007ffc2983e560 R08: 0000000000000000 R09: 0000339d65e80471 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 000017d29dc3b299 2021-08-11 10:20:23 Kernel.Warning 192.168.1.4 Aug 11 10:20:22 VLARPSERV kernel: R13: 0000000001ff3a48 R14: 000000000435ee88 R15: 00000000042d5658

Very nice! Works like a charm on 6.9.0-rc2. Thanks for your efforts!

I'm using DirSyncPro docker on unraid to sync directories to a WebDav location. However, after quiting the app (File > Quit) or just restarting the Docker DirSyncPro does not start up. Following is recorded in the Docker log: When I delete the .pid file from /var/run/mount.davfs/ in the container and restart it, it starts fine. But I have to do this manually every time I restart the Docker. Is there a way to disconnect the WebDav (and delete the .pid file) when the docker shuts down? Config for reference attached.