EDACerton

What do you mean?

The "failure after reboot" is normal and not a big deal -- the service restarts itself after the disks mount/array starts. As for the issue you're seeing -- I did a similar test on my test system (XFS-backed array and ZFS-backed pool) and I can see the activity. BUT... ZFS can do some weird things with file access (like storing small/empty files in metadata and not creating a full file). It's possible that there's something odd with ZFS in the array. I'll have to check on that part.

It's frustrating when I'm trying to respond to help a user and someone interjects with "just use this other one instead". The shfs thing is a limitation of how the array handles file access (essentially, if you access something from /mnt/user, the kernel sees the access as coming from the FUSE filesystem, not from the process that made the request). I'm looking at a way to see though that, but it needs an extra option enabled in the kernel (that isn't currently, but I'm asking about it).

You've posted the link three times on the last page alone with instructions to remove the plugin. Incidentally, the latest update to this plugin provided a big overhaul to the backend, meaning it now monitors the underlying filesystems (substantially more reliable than inotify), and can report what process is causing the activity.

Please stop advertising the other plugin in my support thread.

Are you creating the file on a pool, or on /mnt/diskX, /mnt/user/ ? I'd start by turning the "Enable" features on and removing the exclusions if you want to get a better sense of what's accessing the disks.

I will second adding BTF support. (I have a current plugin project that would benefit from it.) I think the fundamental concern here -- the kernel growing in size -- is due to a misconception with the parameter that's needed. CONFIG_DEBUG_INFO=y results in the kernel including full debug information. This is very large, but not what is needed/being requested. CONFIG_DEBUG_INFO_BTF=y builds the kernel with a compact set of metadata for eBPF. The impact of this should be negligible.

I do this as a volunteer effort, and I don’t have it auto-push because if there’s a problem it could disrupt people’s access to their devices. It’s a preview version, but I’m not going to be reckless either. There’s no harm in the update lagging by a day or two, and usually i have the preview plugin updated the same day.

I do plan to add PID reporting soon (to see what process is accessing files), I just haven’t had the time to do it yet.

# Force correct Tailscale parameters (fix single dash bug)FYI, there's no bug there -- single or double dashes are OK. That fix also won't work since custom-params.sh is rewritten every time Tailscale is started.

This is a simple plugin that replaces the unraid.net link in the WebGUI header with a link back to the WebGUI start page, because I'm tired of clicking that out of habit (expecting it to take me back to the start), only to have it pop up the sales page for the thing that I am already using. 😄 Installationhttps://raw.githubusercontent.com/dkaser/unraid-header-fix/main/plugin/header-fix.plg

Wish granted :)

This topic is not for support of the Tailscale docker integration. Please make a separate post in the Tailscale area for issues related to the docker integration.

Update: it turns out that using the http implementation in rclone doesn't work as smoothly as I would like (it works fine for files in the root, but as soon as you add a subdirectory it breaks). If you update to the latest plugin version, you should be able to add a plain http(s) URL to the config as: https://www.[removed].com/share/share2.txt That should work better.

What happens if you run curl https://… From the command line?

There's nothing that immediately jumps out at me as a problem, but I didn't have a ton of time to look right now. Is the route approved in the admin console? Is there anything else advertising a similar route? Do you have accept routes turned on for the devices you're using remotely?

Please follow the instructions to download Tailscale diags (installing the "Plugin Diag..." app from Community Applications). The system diags don't include information about how Tailscale is configured.

Usually, "I can't access Unraid from the local IP" has something to do with "Accept routes" being turned on. Please provide a Tailscale diagnostics package (see the green message at the top of the page) so that we can see what's going on.

For B2, there's a couple of different options that you can take: Using the S3 provider "Other": :s3,provider=Other,access_key_id=KEY_ID,secret_access_key=APPLICATION_KEY,endpoint=ENDPOINT_FROM_BUCKET_INFO:BUCKET_NAME/piece.txt Using the B2 Provider: :b2,account=KEY_ID,key=APPLICATION_KEY:BUCKET_NAME/piece.txt

The "main" (non-preview) version is available now, and should be in CA soon (just waiting on its approval there).

Please provide plugin diagnostics.

Usually this is related to enabling “Accept DNS”. Otherwise, please provide plugin diagnostics.

This is happening because you're creating a port conflict between Serve/Funnel and the WebGUI. This works OK at first, but eventually causes the WebGUI to break. You need to pick a different port for either one or the other. (Also, you should have a notification in the WebGUI that the config was reset -- this is the plugin protecting you from yourself :) )

OverviewThis plugin automatically unlocks your encrypted disks and starts the array at boot time. The plugin protects your disk encryption key using Shamir's Secret Sharing. Your disk encryption key is stored encrypted on the flash drive, protected by a randomly-generated wrapping key. This wrapping key is split into multiple pieces—you configure how many pieces to create and how many are needed to unlock your drives. At boot, the plugin retrieves the required number of pieces from locations you specify (like web servers, SSH hosts, or DNS records), reconstructs the wrapping key, decrypts your disk encryption key, and unlocks your array automatically. Key FeaturesAutomatic Array Unlock: Automatically unlock encrypted arrays at boot time without manual intervention. Shamir's Secret Sharing Protection: Your disk encryption key is protected by a wrapping key that is split into multiple pieces for enhanced security. Configure how many pieces to create and how many are required to reconstruct the wrapping key No single location stores the complete wrapping key needed to decrypt your disk encryption key Pieces are displayed once during setup as base64 strings—store them securely in accessible locations If pieces are lost, a new set must be generated Flexible Retrieval Methods: Supports most backends available in rclone for retrieving key pieces, and also in DNS TXT records. Examples: HTTP/HTTPS servers: :http,url='https://server.my.ts.net:888/key2': SSH/SFTP servers: :sftp,host=server2.my.net,user=root,key_file=/config/.ssh/id_ed25519:/root/key3 DNS TXT records: dns:testkey.domain.tld Non-Invasive Security: Protects your keyfile with the distributed wrapping key without modifying disk encryption headers or drive configuration. InstallationThis plugin is available via Community Applications. It can also be installed manually. Use the following path to install from the Unraid WebGUI (Plugins -> Install Plugin): Main release: https://raw.githubusercontent.com/dkaser/unraid-auto-unlock/main/plugin/auto-unlock.plg Preview Releases (gets updates more frequently): https://raw.githubusercontent.com/dkaser/unraid-auto-unlock/main/plugin/auto-unlock-preview.plg (Preview) ConfigurationDetailed configuration information is available at https://edac.dev/unraid/auto-unlock/setup/ Changeloghttps://github.com/dkaser/unraid-auto-unlock/releases Feedback & SupportQuestions, suggestions, or issues? Reply to this thread or open an issue on GitHub: https://github.com/dkaser/unraid-auto-unlock/issues

The DNS settings on the Unraid server (Allow Tailscale DNS settings / Accept DNS) don't actually matter for what you're trying to do. Disabling "Unraid services listen on Tailscale IP" is very unusual. Is there a reason for that? I'd also recommend turning "Enable IP Forwarding" on... without that, forwarding for IPv6 might not be enabled (which could be relevant since you're allowing the server to be an exit node). When you reconnected Tailscale on the server, you would have gotten a new Tailscale IP. Did you update that in the rewrite? The DNS configuration in Tailscale looks OK, but there are some cases where it doesn't get applied on the clients (e.g., if an iOS/MacOS DNS profile is installed, using Private DNS on Android).