### System details

Omarchy 4.0.3-1; omarchy-settings 4.0.3-1; Plymouth and SDDM. This report intentionally contains only non-identifying technical details; no full diagnostics or screenshots are attached.

### What's wrong?

Selecting a non-default boot unlock theme on an upgraded installation could not apply the selection. The default artwork remained installed and appeared again at reboot. The blocker was legacy metadata on `/usr/share/plymouth/themes/omarchy`: the directory was owned by the desktop user and had mode `0700`, while the package expects `root:root` and `0755`.

The current `omarchy-plymouth-set` validates destination directories as root-owned before publishing assets. This correctly rejects the legacy directory, but leaves an affected installation unable to apply an unlock theme until its directory metadata is repaired.

#### Observed evidence

- `omarchy plymouth current` reported `default` after the attempted selection.
- `pacman -Qkk omarchy-settings` reported UID, GID, and permission mismatches for `/usr/share/plymouth/themes/omarchy`.
- The installed Plymouth and SDDM logos still matched the packaged default.
- Restoring only that directory to `root:root`, mode `0755`, then running the supported theme setter as the normal user completed successfully. The selected logo matched both installed copies byte-for-byte, and the rebuilt boot image contained the selected artwork and background color.
- The kernel and boot parameters were unchanged by that repair. Post-repair visual confirmation at reboot has not yet been performed.

#### Reproduction conditions

On a disposable test installation with the legacy state already present:

1. Use a real, non-symlink Plymouth theme directory at `/usr/share/plymouth/themes/omarchy`, owned by the desktop user with mode `0700`. Its ancestors and packaged source assets otherwise have their normal root ownership.
2. Select a valid non-default theme through Style > Unlock, or run `omarchy plymouth set by theme <theme>` as the normal user and complete the command's own privilege prompt.
3. The destination ownership check prevents publication; the installed artwork and `omarchy plymouth current` remain unchanged.
4. After restoring the destination directory's packaged ownership and permissions, repeat the same theme selection: application succeeds.

The legacy state and successful repair were observed on the affected installation; the original operation that first changed the directory metadata was not recorded.

#### Relevant upstream history

Commit 695614ce6aa9fdc44f204ad08280813e1a5c4025 changed the older `cp -a` publication to use `--no-preserve=mode,ownership`, preventing staging-directory metadata from being copied into the installed theme directory. PR #8934 later introduced the root-ownership validation. This suggests an upgrade-compatibility gap for installations that already retained the older metadata; it does not establish the exact history of this particular directory.

Please consider a supported repair or migration for this legacy state while retaining the publisher's ownership and symlink checks.

#### Related reports checked

- #6864 and PR #6865 concern package updates overwriting a theme that was applied successfully. This report concerns application being rejected before any new assets are published; reapplying the theme alone fails until the directory ownership is repaired.
- #10036 concerns invoking an older setter under `sudo` with missing environment. The affected path here uses the normal user's menu/theme command and its internal elevation.
- PR #8934 is the related merged security change, not a request to weaken that validation.

Open and closed issues and PRs were searched for Plymouth/unlock selection, ownership, permissions, legacy directory state, and publication refusal. No existing report specifically covering this legacy-ownership failure was found.