dlandon

That can be fixed.

The 'Help' button is your friend.

- Remove both disks and then delete them from the historical devices. - Verify the /mnt/disks/AMCC_9650SE_12M_DISK mount point is not there. If it is unmount it and then rm -rf /mnt/disks/AMCC_9650SE_12M_DISK. If you can't clear it up, reboot the server. - Install one disk and change the mount point. Remember to hit <Return> to save the new mount point name. - Mount this disk and be sure the mount point is what you set. If not the config file is probably corrupted. - If this works add the second disk and change the mount point. If this doesn't work, post your /flash/connfig/plugins/unassigned.devices/unassigned.devices.cfg file and let me see what it contains.

Zoneminder updated to 1.30.4. Release notes are here. The changes are a security update and some package adjustments for the api (used by zmNinja) that I already handled. The updated Docker will update your Zoneminder and database in place.

Write errors would be a problem. Once UD has mounted a drive, any issues with reading, writing, and un-mounting would be logged in the syslog and not in the UD log.

See if the syslog has any entries that would indicate an unmount.

Your disk drives are showing very high 'Raw_Read_Error_Rate' and 'Seek_Error_Rate' numbers. I'd look into that. I see nothing else that could cause the spin up issue you are seeing.

I cannot reproduce the issue you are seeing with UD disk spin ups. Post your diagnostics for me to look at.

I don't see the problem on my system. Drives spin down with no problem. If you have the drives mounted and shared, there may be a client computer scanning the disks regularly causing a spin up. Turn off the Share switch and see if the drive stays spun down. Are you using the cache_dirs plugin?

I don't see how it's a bug in UD. UD has nothing to do with the notifications and I don't think the UD drives are scanned by the notification scan. What type of drives are you seeing spinning up?

Please read the second post about drives spinning up. Some drives will spin up when queried about their standby status.

That's one of the reasons I updated LMS.

Done. The file directory in the recycle bin is created when the file is deleted so it will show the date/time when the file(s) were deleted, but the modify date/time on the files will remain unchanged. Files will be purged from the recycle bin when the access date/time (which is the deletion date/time) ages the file.

It looks like I could switch to not update the modify date (recycle:touch_mtime = 'No') , but update the access date (recycle:touch = 'Yes') and use that to purge the files. I would then use 'find -atime' to purge files from the recycle bin.

The mtime date is used to age the files in the recycle bin using 'find -mtime...', so that date has to be modified when put in the recycle bin. The access time is not updated on unRAID shares because of the way disks are mounted: mount -t xfs -o noatime,nodiratime /dev/md1 /mnt/disk1 I'm not sure what value the access date would have if it is not changed going to the recycle bin because the access date is not kept current.

LMS updated to 7.9.1.

It looks like I need to install ssmtp in the docker. EDIT: I'm working on updating the docker and will add ssmtp. The ssmtp configuration files will be at appdata/Zoneminder/ssmtp.

As far as I know, you just configure it in the options of Zoneminder.

I've removed the perl scripts from the appdata/Zoneminder folder. These files change with each version of Zoneminder and can't be persistent between versions. I think these scripts were exposed so users could customize the scripts. This presents problems in updating Zoneminder because they change on each version and I'm not sure it is really a good idea to modify them.

I am removing all previous versions of this docker. You will need to update by using the latest template. I recommend you backup your appdata first. To setup for the latest docker template: Remove the Zoneminder docker container. Search for the Zoneminder template in CA. Install the new Zoneminder template with any changes for your particular situation. Your configuration will be kept and the database updated. I am only going to maintain this docker with the latest version of Zoneminder for the following reasons: Maintaining and supporting previous versions is too much work. You can't roll back versions once the database has been updated. Previous versions have security issues.

Thanks for letting me know. I'm going to rework the repository and the template to have a single version of the Zoneminder docker that will do in place updates. Maintaining older versions is not my idea of a good time, and the security of previous versions is suspect. People should be using the latest version.

I just released the docker for Zoneminder version 1.30.3. I finally achieved an in place version update! Version 1.30.3 of the Zoneminder docker will now update a previous Zoneminder version in place. Just edit the docker, select the 1.30.3 repository and apply. Your Zoneminder will update in place and your configuration will be kept. You no longer have to start from scratch when updating Zoneminder versions. Because of the ease in updating now, I encourage you to update to version 1.30.3 due to improved security. Previous versions have security issues.

That appears to be a SMB or network issue with the client computer.

Because of the limited space in /var/log, I have moved the device script logs to /tmp/unassigned.devices/ in the latest version. If you have a device script log you want to preserve, go to the command line and move the log from /var/log/ to /tmp/unassigned.devices, or use MC or other file manager to move the device script log files.

No. That's how the samba vfs recycle works and I have no control over that.