dlandon

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.