Disable SMB3 unix extensions by default
This commit disables the SMB3 unix extensions by default. They
will be exposed as a configurable option in a future PR.
NAS-139180 / 25.10.2 / Change error on core.bulk op to LongString (by anodos325) (#17957)
Depending on the circumstances and exact arguments passed to a method,
the operation may fail with a detail python traceback that requires a
LongString for the error message.
Original PR: https://github.com/truenas/middleware/pull/17956
Co-authored-by: Andrew Walker <awalker at ixsystems.com>
NAS-139199 / 25.10.2 / Fix Futures resource leak in run_coroutine_threadsafe (by yocalebo) (#17969)
This fixes a leak whereby we're not tracking `Future` objects correctly.
This means they're never cleaned up and overtime they'll build up on the
main event loop.
I confirmed this behavior by running `midclt call interface.query` in a
tight loop on a box and then connecting a remote pdb session with the
middleware process. It was designed to "overrun" the main event loop,
what it did was build up a queue that never cleared itself. There were
~2.3k PENDING futures in our thread pool.
This does 2 things:
1. creates a `run_coroutine_threadsafe` wrapper that properly tracks the
futures so they're cleaned up
2. logs any exceptions that may occur in these "fire and forget"
futures.
Original PR: https://github.com/truenas/middleware/pull/17967
Co-authored-by: caleb <yocalebo at gmail.com>
NAS-139200 / 26.04 / Force name keyword arg in start_daemon_thread (#17968)
While tracing middlewared process, I found a bunch of threads attached
to parent process with just names like `Thread-0`, `Thread-1`, etc. This
is the default thread_name_prefix given to a `Thread` in python. That's
unhelpful so this forces a `name` keyword argument to be given to
`start_daemon_thread`.
NAS-139199 / 26.04 / Fix Futures resource leak in run_coroutine_threadsafe (#17967)
This fixes a leak whereby we're not tracking `Future` objects correctly.
This means they're never cleaned up and overtime they'll build up on the
main event loop.
I confirmed this behavior by running `midclt call interface.query` in a
tight loop on a box and then connecting a remote pdb session with the
middleware process. It was designed to "overrun" the main event loop,
what it did was build up a queue that never cleared itself. There were
~2.3k PENDING futures in our thread pool.
This does 2 things:
1. creates a `run_coroutine_threadsafe` wrapper that properly tracks the
futures so they're cleaned up
2. logs any exceptions that may occur in these "fire and forget"
futures.
Fix replication mount conflict for ix-apps datasets
This commit fixes an issue where replicating ix-apps datasets would fail with a mount conflict after switching Docker pools.
When Docker switches to a pool, it sets `mountpoint=/.ix-apps` on that pool's ix-apps dataset. If the user later switches back to the original pool and runs replication again, zfs recv attempts to auto-mount the destination dataset at `/.ix-apps`, conflicting with the currently active ix-apps dataset.
The fix disables automatic mounting (adds -u flag to zfs recv) when the source dataset is a Docker ix-apps dataset `({pool}/ix-apps` or its children). Docker's `fs_manage.mount` handles mounting separately when needed.
NAS-139194 / 25.10.2 / Properly set address family in ConnectionOrigin (by anodos325) (#17965)
This commit fixes the handling for AF_INET6 origin in the TrueNAS
ConnectionOrigin. Our internal validation was determining correct
address family, but it wasn't being set in family attribute.
Original PR: https://github.com/truenas/middleware/pull/17964
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
Properly set address family in ConnectionOrigin
This commit fixes the handling for AF_INET6 origin in the
TrueNAS ConnectionOrigin. Our internal validation was determining
correct address family, but it wasn't being set in family
attribute.
(cherry picked from commit e43808a86400aa9a4e5ec191616c589890b9db88)
NAS-139194 / 26.04 / Properly set address family in ConnectionOrigin (#17964)
This commit fixes the handling for AF_INET6 origin in the TrueNAS
ConnectionOrigin. Our internal validation was determining correct
address family, but it wasn't being set in family attribute.
Properly set address family in ConnectionOrigin
This commit fixes the handling for AF_INET6 origin in the
TrueNAS ConnectionOrigin. Our internal validation was determining
correct address family, but it wasn't being set in family
attribute.
