dlandon

Sounds like a shm memory issue. What value do you have set for shm in the docker template? Click on "Show More Settings" to see. How much memory do you have in your server?

Verify the 'ServerName' file in the appdata/zoneminder/keys/ folder contains 'localhost'.

Click on the "Basic View" switch on the docker page to switch to advanced view in the upper right corner and then click "Force Update" on the docker. Check the timezone on the docker start command and see if it is the correct timezone.

I updated the plugin. I reverted some aggressive offloads from the 6.8 beta testing. I was having an issue with offloads when I was running the 6.8 beta and was experimenting with disabling offloads. I removed those aggressive offloads and it appears that one of those was causing the NIC to reset. Probably will fix your issue.

It's possible that the NICs you use take a while to apply the settings. It should be very quick. What NICs are you using? You could delay the start up of your troublesome dockers by setting a delay and/or controlling the order the dockers start. I'm not interested in chasing down a problem that has only come up for one user. If it occurs a lot, I might be able to spend some time on it. Right now if I change the event that the plugin uses to apply the settings, it may create more issues for other users. This is the first time this has come up.

This is not right. It should be: 'datadirectory' => '/data', DON'T CHANGE IT!

You are over complicating the installation. Remove the docker and appdata folder. Install ownCloud docker and set data path to '/data'. Do not enter anything else! Once the docker has started and you have logged on successfully, copy your data to the /mnt/user/appdata/ownCloud/data. Don't move it! Then set 'filesystem_check_changes' => 1. The keys go to /mnt/user/appdata/ownCloud/keys.

Manually is the only way.

There are so many different NICs and each will handle things differently. Tips and tweaks is available for you to make changes if you have issues. Some people have reported issues with flow control and offload enabled. If disabling those doesn't work for you, leave them enabled.

There is nothing for me to address in the plugin. You make changes based on your own needs and there is no guarantee that the changes won't cause any problems. Some people have reported issues with flow control and offloads. If disabling those doesn't work for you, then leave them enabled.

Be sure the UD disk is unmounted and then open a terminal window and enter: /usr/local/sbin/emcmd 'cmdCryptsetup=luksOpen /dev/sdk1 Crucial_1TB --allow-discards' Post the results of the command.

Post diagnostics. There will be more in the log after that.

I've added some debug to UD. Please update the UD plugin and try to mount again. Post diagnostics after.

You've already posted this as a 6.8 bug. Double posting doesn't get you an answer any faster and adds confusion. We will work on this issue there, not here.

Return the results of the luksOpen command and I'll log it. I can take appropriate action based on the results. If it fails, I don't want to attempt a mount. I'll add some debug so we can see better what is happening.

He's running the latest. Why would emcmd not run? Or not appear to run? Edit: The emcmd is not running and is not returning to UD. UD will either attempt to mount the disk or report an error after the emcmd command. Neither of those is happening.

It has been updated to work with the api. Post your diagnostics so I can take a look.

This is what the log should show when the keyfile is not found: Oct 14 18:22:19 BackupServer unassigned.devices: luksOpen: key file not found - using emcmd to mount. Oct 14 18:22:19 BackupServer emhttpd: req (7): cmdCryptsetup=luksOpen /dev/sdg1 Test_Disk --allow-discards&csrf_token=**************** Oct 14 18:22:19 BackupServer unassigned.devices: Mount drive command: /sbin/mount '/dev/mapper/Test_Disk' '/mnt/disks/Test_Disk' Oct 14 18:22:19 BackupServer unassigned.devices: Mount of '/dev/mapper/Test_Disk' failed. Error message: mount: /mnt/disks/Test_Disk: special device /dev/mapper/Test_Disk does not exist. Oct 14 18:22:19 BackupServer unassigned.devices: Partition 'WDC_WD3200AAJS-65M0A0_WD-WMAV21954758' could not be mounted... O I don't have an encrypted array and there is no password in my system. I would expect the mount to fail. What I don't understand is I don't see the emhttp command being executed in the log file. It should try to mount the disk after the emhttp command is executed, or print an error if the command returned an error. I see neither. The difference here is that your array is all encrypted. Mine is not.

Unassigned Devices has been updated to deal with this change. This means UD didn't find the key file and is using the new API. I do not have an encrypted array and could only do limited testing. Not sure if this is a UD issue or the API. There are no entries in the log to indicate what went wrong.

The array appears to be waiting for the password. Unassigned devices can't mount the device because there is no password. I don't use encrypted disks, but I believe that you need to enter the password before the array will start.

I suspect this has something to do with it: https://groups.google.com/forum/#!topic/linux.kernel/XiX6X3JNbaE Here's the Linux code for tun.c: https://github.com/torvalds/linux/blob/master/drivers/net/tun.c Looks like it is intended to log once then never again.

When I had this problem in the beta series, I reworked the Tips and Tweaks plugin to turn off GSO and all offloading on Nics, it made no difference. From what I remember, everything worked fine, it’s just a flood of log messages that would eventually crash the server from the log growing too large.

I use a remote Unraid server in another state as a backup and I also manage the server. I've been using Wireguard since it was first introduced in the beta testing of 6.8 and I find it to be incredibly easy to set up and very reliable. A lot simpler than OpenVPN to setup, and appears to be much faster. It is still in development and I don't think it has been certified yet. The developers warn that is not fully ready for prime time and should not be used in production. I personally don't think that is a problem for us. If I were a financial institution, I would not use it until it has been certified. The bad guys are lazy and won't spend much time trying to hack into our networks, Wireguard will discourage them and they'll move on.

Good answer.

I originally thought it was a VM issue also, but I think it's really the build up of the number of dockers and VMs using static ip addresses. This is a strange problem with networking. I don't know how LT will be able to find a solution to this.