The fstab-only mount method explicitly says "for LXC bind-mounts" in
its dialog wording, but the mount point left behind by mkfs +
mkdir is owned root:root with mode 0755. An unprivileged LXC sees
the directory through its uid offset (root inside → host uid 100000)
which lands under the directory's "others" bits — so the container
can read but never write, and the user has to track down the
chmod / setfacl step manually.
lxc-mount-manager_minimal.sh already offers exactly this fix as
`lmm_offer_host_permissions` when the user adds the bind-mount
through that script, but the disk-side script never closed its half
of the loop. Add a small `_apply_lxc_bind_mount_perms` helper that
runs `chmod o+rwx` plus `setfacl o::rwx + default ACL` whenever
MODE_FSTAB=1, and call it from both `mount_disk_permanently`
(format path) and `mount_existing_disk` (use_existing path). Pure
pvesm-only mounts keep the original behaviour — chmod o+rwx on a
VM/backup storage isn't desirable.
Verified on .55 against the existing /mnt/disk-sda + LXC 112
(unprivileged): unprivileged container root could not write before
(Permission denied), writes succeed after the perms are applied and
land on the host as uid 100000 as expected.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two related gaps in the disk-host script that surfaced while testing
the new dual-flow (pvesm / fstab-only / both) added earlier today.
view_disk_storages used to read only from `pvesm status`, so a disk
added via the new fstab-only path — exactly the case where the user
wants a local disk available for LXC bind-mounts without registering
it as a Proxmox storage — never showed up. Replicate the same fstab
scan remove_disk_storage already performs and list those mounts in a
second section underneath the pvesm ones. Empty state and wording
updated so the panel no longer claims "No local storage configured
in Proxmox" when fstab-only mounts are present.
Both view_disk_storages (new code) and remove_disk_storage (existing
fstab branch) were happily picking up `/mnt/Archivos` and any other
CIFS/NFS share mounted under /mnt. samba_host.sh and nfs_host.sh own
those — surfacing them in the local-disk menus would let a user
remove a network share from the wrong screen. Filter by fstype
(skip cifs/smbfs/nfs/nfs4/nfsv4/sshfs/fuse) and additionally require
that the resolved source be a real block device, which drops bind
mounts and anything else whose backing source isn't a disk.
Verified on .55 with the test disk-sda fstab-only mount alongside
the existing //192.168.0.15/Archivos CIFS mount: only disk-sda is
listed by the local-disk view/remove flows.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two release-day fixes in the host-side share tooling, both reported
during testing of the v1.2.2 candidate.
lxc-mount-manager_minimal.sh
After adding a mount point on a stopped LXC the script offered to
`pct reboot $ct` unconditionally — which fails on a stopped CT
because `pct reboot` only accepts running ones, so the user saw a
bogus "Failed to restart" right after a successful mount. Gate the
prompt on `pct status` and, when the CT is stopped, tell the user
the mount will activate on next start instead of trying to reboot
it. The matching restart prompt in the remove flow (around line
540) was already doing the check correctly; this just brings the
add flow in line.
disk_host.sh
The script always registered the disk as a Proxmox storage via
`pvesm add dir|zfspool`. nfs_host.sh and samba_host.sh already
offered a dual-flow chooser ("Proxmox storage" / "host fstab only"
/ both) so a user could mount the share on the host for LXC
bind-mounts without surfacing it as a Proxmox storage. Replicate
that chooser for local disks:
* new `select_mount_method` checklist with `pvesm` and `fstab`,
inserted after filesystem selection. ZFS is forced into the
pvesm path because a ZFS pool can't be expressed as an fstab
mount.
* `configure_disk_storage` skips the Content Types prompt when
only fstab is selected and renames "Storage ID" → "Mount Name"
in the same case so the wording matches what the user will
actually see (or not see) in Proxmox.
* `format_and_mount_disk` title and summary lines adapt to the
chosen mode.
* the trailing `add_proxmox_dir_storage` call in `add_local_disk_storage`
runs only when `MODE_PVESM=1`; in fstab-only mode the final
message points users at the LXC Mount Manager for bind-mounts.
Verified end-to-end on a 32 GB USB disk against LXC 112
(unprivileged) on .55: fstab-only path → bind-mount → root inside
CT writes mapped to host uid 100000, regular user writes mapped to
host uid 101000, both reads/writes successful from inside the
container.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three changes that fold into the v1.2.2 release PR:
1. AppImage: bump Next.js 15.1.6 -> 15.1.9 (CVE-2025-55182)
GHSA-9qr9-h5gf-34mp / React2Shell is a pre-auth RCE in React Server
Components when Server Functions deserialize attacker payloads. The
ProxMenux Monitor ships Next.js in `output: "export"` mode behind
Flask on :8008, so there is no runtime Next.js server and no
"use server" directive in the source tree — the exploitable path is
not reachable. Bumping to 15.1.9 anyway because OpenVAS and similar
scanners flag the version string from the JS bundle regardless of
architecture; raising the floor removes false-positive noise across
every install. Reported by @rost43 in #219.
2. web/components/ui/doc-navigation.tsx: handle sidebar entries that
point to in-page anchors. The Storage Share Manager sidebar has
entries for `/docs/storage-share#host` and
`/docs/storage-share#lxc-net` as section headers, but
usePathname() does not include the hash so every visit collapsed
to the parent page. As a result Next/Previous on /docs/storage-share
stayed stuck at #host, and Next from .../lxc-mount-points/ pointed
back at #host instead of #lxc-net. Read window.location.hash on
mount (and on hashchange) and try the pathname+hash match before
falling back to the pathname-only lookup. SSR hydrates with an
empty hash and refreshes once mounted — brief render before
hydration is the same as the previous behaviour, so no regression.
3. scripts/help_info_menu.sh: user-side improvement (mirrored from
develop).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
MacRimi