dlandon

UD has no idea where the remote mount server is located. If it is on-site (LAN), your argument makes sense. If the server can only be reached on the Internet, then pinging the gateway makes sense. If the gateway was not available the remote mounts would fail if they are on the Internet.

UD does a network test before mounting remote shares. The test for the network being available was not successful. This check is after the array is started. The network should be available then. If the GUI is not reachable, UD cannot mount remote devices because the network is not ready. The UD test for the network being available is by trying to ping your gateway device for 30 seconds. If there is no response, UD thinks the network is not available. Generally the gateway is your router. Check your network setup in Unraid.

It didn't. It never mounted. Click the '+' icon on the disk on the UD web page. You'll see a check mark when the disk us not mounted. That does a file system check. On 6.9 there is a tab called 'Pool Devices'. Add your disk drive there as an additional device (It's like an additional cache disk) and give it a meaningful name. Your VM can then read/write that disk. Unraid manages the disk. This is not recommended. You can do this as a 'Pool Device'.

Your disk is not mounting: Apr 3 23:45:09 Tower unassigned.devices: Adding disk '/dev/sdd1'... Apr 3 23:45:09 Tower unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdd1' '/mnt/disks/CCTV' Apr 3 23:45:09 Tower kernel: XFS (sdd1): Mounting V5 Filesystem Apr 3 23:45:09 Tower kernel: XFS (sdd1): Starting recovery (logdev: internal) Apr 3 23:45:09 Tower kernel: XFS (sdd1): Corruption warning: Metadata has LSN (1:10968) ahead of current LSN (1:10840). Please unmount and run xfs_repair (>= v4.3) to resolve. Apr 3 23:45:09 Tower kernel: XFS (sdd1): Metadata corruption detected at xfs_agi_verify+0x63/0x12e [xfs], xfs_agi block 0x575428e8 Apr 3 23:45:09 Tower kernel: XFS (sdd1): Unmount and run xfs_repair Apr 3 23:45:09 Tower kernel: XFS (sdd1): First 128 bytes of corrupted metadata buffer: Apr 3 23:45:09 Tower kernel: 00000000: 58 41 47 49 00 00 00 01 00 00 00 01 0a ea 85 1b XAGI............ Apr 3 23:45:09 Tower kernel: 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 18 ...@............ Apr 3 23:45:09 Tower kernel: 00000020: 00 00 00 80 ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Apr 3 23:45:09 Tower kernel: XFS (sdd1): metadata I/O error in "xfs_read_agi+0x7c/0xc8 [xfs]" at daddr 0x575428e8 len 8 error 117 Apr 3 23:45:10 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2002.0" x-pid="6459" x-info="https://www.rsyslog.com"] start Apr 3 23:45:11 Tower kernel: e1000e 0000:00:1f.6 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Apr 3 23:45:11 Tower kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Apr 3 23:45:11 Tower kernel: bond0: (slave eth0): making interface the new active one Apr 3 23:45:11 Tower kernel: device eth0 entered promiscuous mode Apr 3 23:45:11 Tower kernel: bond0: active interface up! Apr 3 23:45:11 Tower kernel: br0: port 1(bond0) entered blocking state Apr 3 23:45:11 Tower kernel: br0: port 1(bond0) entered forwarding state Apr 3 23:45:11 Tower kernel: br0.10: port 1(bond0.10) entered blocking state Apr 3 23:45:11 Tower kernel: br0.10: port 1(bond0.10) entered forwarding state Apr 3 23:45:11 Tower kernel: br0.20: port 1(bond0.20) entered blocking state Apr 3 23:45:11 Tower kernel: br0.20: port 1(bond0.20) entered forwarding state Apr 3 23:45:13 Tower ntpd[2022]: Listen normally on 4 br0 192.168.1.4:123 Apr 3 23:45:13 Tower ntpd[2022]: new interface(s) found: waking up resolver Apr 3 23:45:53 Tower unassigned.devices: Mount of '/dev/sdd1' failed. Error message: mount: /mnt/disks/CCTV: mount(2) system call failed: Structure needs cleaning. Apr 3 23:45:53 Tower unassigned.devices: Partition 'WDC_WD30PURX-64P6ZY0_WD-WCC4N1YZ4A93' cannot be mounted. There is a protection on UD disks that prevents the tmpfs file system from filling up when a UD disk is written to but not mounted. It's very small, that's why you are seeing the 100% full message. Click on the check mark next to the disk partition to attempt a repair. Make sure you can mount the device before the VM writes to the disk. You should move this disk to a pool device to prevent this kind of problem.

I'm not sure I understand what is going on here, but qemu is using a lot of CPU. The z... are Zoneminder: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24907 root 20 0 4764404 2.6g 23340 S 73.7 13.2 51:02.08 qemu-syst+ 27136 sshd 20 0 588660 407792 392180 R 47.4 2.0 0:02.64 zmc 28130 sshd 20 0 41796 17720 4724 R 36.8 0.1 0:00.76 zmdc.pl 27793 sshd 20 0 55924 38896 11760 R 26.3 0.2 0:01.62 zmfilter.+

There are several things to look out for in the latest version of ownCloud (10.7): Support for version 7.2 of php will be removed in an upcoming minor release. You can set the php version to use in the docker template. I recommend you use the latest version of ownCloud and php 7.4. You will receive a security warning that is easily fixed by editing the appdata/owncloud/nginx/site-confs/default file and change the line - add_header X-XSS-Protection "0";

Unraid has nothing to do with CPU governors. The schedutil governor has been under development, and still is as far as I know. it has probably changed in the latest version of Linux causing the differences you see.

There is no file system on the first partition. The second partition has a problem with an explanation on how to sort it out: Apr 2 16:42:42 u unassigned.devices: No filesystem detected on '/dev/sdb1'. Apr 2 16:42:42 u unassigned.devices: Partition 'WDC_WD100EFAX-68LHPN0_JEJ0YKMM-part1' cannot be mounted. Apr 2 16:42:42 u unassigned.devices: Adding disk '/dev/sdb2'... Apr 2 16:42:42 u unassigned.devices: Mount drive command: /sbin/mount -t ntfs -o ro,auto,async,noatime,nodiratime,nodev,nosuid,nls=utf8,umask=000 '/dev/sdb2' '/mnt/disks/TV' Apr 2 16:42:42 u unassigned.devices: Mount of '/dev/sdb2' failed. Error message: does not match (record 32). Failed to mount '/dev/sdb2': Input/output error NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation for more details. Apr 2 16:42:42 u unassigned.devices: Partition 'TV' cannot be mounted.

Did you unmount it before trying to mount it with the user script? Either one will work.

Your cache disk is very full: /dev/sdb1 466G 444G 22G 96% /mnt/cache It appears to be a btrfs disk and I've seen some posts about btrfs disks causing high cpu usage. I'm not sure it's a good idea to run your cache disk that full. It depends on your particular use case. There is a preferred way to do this in 6.9.1: #Setup drivers for hardware transcoding in Plex modprobe i915 chmod -R 777 /dev/dri The Intel driver has some issues in later versions of Linux.

Post your complete diagnostics. This incremental approach is not getting to the heart of the problem.

The reason I asked was that it sometimes causes errors. I wasn't suggesting you add it to solve your problem.

Are you using the /dev/dri GPU driver in the docker container?

Check your camera buffers: These are the settings I use and I have no problems.

How are you passing through the disk? Does the VM mount the disk? Unraid is actually doing the disk monitoring and notification.

How do you know it is this docker container? There have been many reports of 100% CPU, but no one has implicated Zoneminder.

UD will try all versions of SMB until successful and will eventually try 1.0. You don't need to force it to 1.0. You probably haven't created the script file yet. The edit settings only shows the proposed script file name if one hasn't been created. If you can't mount a SMB mount, post diagnostics so we can have a look.

I'm releasing a new version that will allow specifying an excluded directory in a particular share. You specify a specific share directory to exclude by: share/directory The full mount path is not necessary. /mnt/user/ is assumed. If you want to specify a directory to be excluded in all shares just use: directory You can exclude UD mounted disks also by: mountpoint/directory The full mount path is not necessary. /mnt/disks/ is assumed.

You could create unique names. I'll have to look at possibly a way to exclude directories by share.

The database has issues. Remove the docker container and the appdata/Zoneminder folder and start over.

What does the docker log show?

A better wild card would be - Unraid?Downloads.

You could probably also escape the space character - Unraid\ Downloads.

Try single quotes.

Quote it 'Unraid Downloads".