limetech

If you don't mind please try this. First Stop array and then take note of what device id is assigned to one of your data disks, doesn't matter which one. Let's say you pick 'sdb'. Then type this: cryptsetup luksOpen /dev/sdb1 sdb1 The command should prompt you to enter your passphrase, please do so and hit Enter. If the command succeeds it will simply exit; if not it will spit out an error. If it succeeds, you should then type this: cryptsetup luksClose sdb1 Please let me know what happens.

What device(s) do you have encrypted? Meaning, cache, disk1, disk2, ... which ones?

Added additional Intel BT firmware to 6.8.1-rc1. Please give it a try.

We added thrundebolt kernel support in order to start experimenting with it ourselves and per a user request, but we have done nothing yet. Got a link to boltd/boltctl project?

Note that symlinks (soft links) are fine, it's hard links which present a problem.

Changed Status to Open Changed Priority to Annoyance

I can hear your frustration, but please let's keep the dialog friendly 😎 The current codebase we're using for ttyd is from 2019.10.25 and as you can see there have been several commits since then. I'll update to their latest commit in next release.

Please give this a try: start lopping off characters from the end of your passphrase and see if it gets to a point where it's recognized. For example, say passphrase is: 123456789 try 12345678 then try 1234567 etc.

Changed Status to Retest

Changed Status to Retest

Please try 6.8.1-rc1 to see if your passphrase is now correctly recognized:

To install this release, navigate to Tools/Update OS and select the Next branch. This release fixes an issue with entering encryption passphrase via webGUI. In addition, we updated libvirt and qemu to latest versions where bugs which caused us to revert to previous versions appear to be fixed. For these reasons, I want to have a brief pre-release for wider testing before publishing to stable branch. Bugs: If you discover a bug or other issue in this release, please open a Stable Releases Bug Report. Version 6.8.1-rc1 2020-01-06 Base distro: kernel_firmware: version 20191118_e8a0f4c (with additional Intel BT firmware) libvirt: version 5.10.0 php: version 7.3.13 (CVE-2019-11044 CVE-2019-11045 CVE-2019-11046 CVE-2019-11047 CVE-2019-11049 CVE-2019-11050) qemu: version 4.2.0 samba: version 4.11.4 wireguard-tools: version 1.0.20191226 Linux kernel: version 4.19.93 CONFIG_THUNDERBOLT: Thunderbolt support CONFIG_INTEL_WMI_THUNDERBOLT: Intel WMI thunderbolt force power driver CONFIG_THUNDERBOLT_NET: Networking over Thunderbolt cable oot: Highpoint rr3740a: version v1.19.0_19_04_04 oot: Highpoint r750: version v1.2.11-18_06_26 [restored] oot: wireguard: version 0.0.20191226 Management: add cache-busting params for noVNC url assets fix cryptsetup passphrase truncation network: disable IPv6 for an interface when its settings is "IPv4 only". webgui: Management page: fixed typos in help text webgui: VM settings: fixed Apply button sometimes not working webgui: Dashboard: display CPU load full width when no HT webgui: Docker: show 'up-to-date' when status is unknown webgui: Fixed: handle race condition when updating share access rights in Edit User webgui: Docker: allow to set container port for custom bridge networks webgui: Better support for custom themes (not perfect yet) webgui: Dashboard: adjusted table positioning webgui: Add user name and user description verification webgui: Edit User: fix share access assignments webgui: Management page: remove UPnP conditional setting webgui: Escape shell arg when logging csrf mismatch

I'm preparing the release now.

Right well my comment was only partially sarcastic. Lots of issues with NFS over the years, especially with security.

We don't use hard links. With 'support hard links' set to 'no' then if a file operation attempts to create a hard link it will fail with ENOTSUP error. This is because two directory entries that refer to same file must return the same 'inode' number, and this is not supported by FUSE. But FUSE does support passing the inode number as-is from a file. But the problem you run into is if he file physically moves from one file system to another, eg, from cache to diskN, then the inode number changes but the file path via /mnt/user does not. Yes we should do that. Maybe add third setting 'auto' - which will turn off hard link support if NFS enabled and turn it on if disabled.

Changed Status to Solved Changed Priority to Other

see here:

There are two NFS-related tunables: First on Settings/NFS Settings there is: Tunable (fuse_remember): 330 The value 330 means 5 1/2 minutes. The Help for this setting explains it. and new in 6.8 on Settings/Global Share Settings there is: Tunable (support Hard Links): Yes Change to No, and see if issue still happens. Hard links in user shares will not be supported but the file handle should stay consistent. This is happening because, like AFP, NFS is an outdated archaic protocol which relies on being able to associate any file with a number, and looking that file up by the number (as opposed to SMB which is path-based). This makes it nearly impossible to use with any stacking file system.

This one is in the works. Edit: actually, doesn't mess with syslinux.cfg file, instead it generates entries in config/vfio-pci.cfg

sleep is overrated

We got to the bottom of this, though not sure why it's happening ... When vm-manager (libvirt) is started we first mount a loopback image at /etc/libvirt. This stores the vm config data such as the xml files. If a docker container is started after that loopback is mounted, then for some reason, unmounting the loopback (which happens when you disable libvirt) does not release the device attachment of /dev/loopX to the loopback file. If you stop the container, then the loopback device is released. It's as if the container does a 'cd /etc/libvirt'. But really this has nothing to do with libvirt. Any loopback mounted file anywhere in the root directory tree, except within /mnt (which is bind-mounted to itself at startup) will exhibit this behavior. Not sure why this is happening - some kind of crazy interaction between container isolation and device mounts in the kernel I think. The obvious workaround for Unraid is to not permit changing libvirt enable/disable unless array is Stopped.

This is with docker.img loopback file located on cache correct?

Changed Status to Solved Changed Priority to Other

Changed Priority to Other

Changed Status to Closed