mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 10:52:22 +00:00
Merge pull request #490 from jcastro/docs/review-storage-share
docs: review storage sharing documentation in all seven translations
This commit is contained in:
MacRimi
@@ -98,7 +98,7 @@
|
||||
"noLunTitle": "LUNs do not appear in /dev/disk/by-path after registering",
|
||||
"noLunBody": "<code>pvesm add iscsi</code> succeeded but the kernel is not seeing block devices. Check <code>iscsiadm --mode session</code> — if no session is active, start one manually with <code>iscsiadm --mode node --login</code>. If a session exists but no LUNs appear, force a rescan: <code>iscsiadm --mode session --rescan</code>. If still nothing, the target probably has no LUNs assigned to this IQN yet (configure LUN mapping on the target).",
|
||||
"chapTitle": "CHAP authentication",
|
||||
"chapBody": "ProxMenux does not expose the CHAP username / password fields in the interactive flow. If your target requires CHAP, register with ProxMenux first (discovery with CHAP may fail, but <code>pvesm add</code> will still write the entry), then add credentials manually: <code>pvesm set <id> --username <chap-user></code> and edit <code>/etc/iscsi/iscsid.conf</code> with the password, then <code>systemctl restart iscsid</code>. This is a gap in the current script — documented here so you know what to do."
|
||||
"chapBody": "ProxMenux does not expose CHAP username/password fields in the interactive flow. If discovery fails, the script stops before <code>pvesm add</code>; it does not register the storage anyway. Configure the target’s CHAP requirements separately in <code>open-iscsi</code>, including discovery authentication when required, then retry. Use <code>iscsiadm</code> to check the configuration and verify active sessions with <code>iscsiadm --mode session</code>."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
},
|
||||
"destructive": {
|
||||
"title": "Destructive tool for the 'format' path",
|
||||
"body": "The <em>Format</em> path <strong>erases every partition and byte on the selected disk</strong>. ProxMenux shows the disk list with a warning banner, filters out disks already in use, and requires an explicit confirmation before any <code>wipefs</code> / <code>sgdisk</code> / <code>mkfs</code> runs. Still — read the device path aloud twice before typing \"yes\"."
|
||||
"body": "The <em>Format</em> path <strong>destroys the existing partitions and data on the selected disk</strong>. ProxMenux shows the disk list with a warning banner, filters out disks already in use, and requires confirmation before any <code>wipefs</code> / <code>sgdisk</code> / <code>mkfs</code> runs. This is not a secure overwrite of every byte. Double-check the device path before confirming."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "Directory vs ZFS pool — which to pick",
|
||||
@@ -78,7 +78,7 @@
|
||||
"Pick the filesystem — see the table above for trade-offs.",
|
||||
"Storage ID (default <code>disk-<device></code>), mount path, content-type preset.",
|
||||
"Confirm at the <strong>FINAL CONFIRMATION — DATA WILL BE ERASED</strong> dialog.",
|
||||
"ProxMenux wipes the partition table, creates one partition spanning the whole disk, runs <code>mkfs.<fs></code> (or <code>zpool create</code>), mounts it, adds it to <code>/etc/fstab</code> by UUID with <code>defaults,nofail</code>, and registers it in Proxmox via <code>pvesm add dir</code> or <code>pvesm add zfspool</code>."
|
||||
"ProxMenux clears the partition table and creates one partition spanning the disk. It runs <code>mkfs.<fs></code> or <code>zpool create</code> and mounts the result. Regular filesystems get an entry in <code>/etc/fstab</code> by UUID with <code>defaults,nofail</code>; ZFS uses its pool mount configuration instead. If <em>As Proxmox storage</em> is marked (always the case for ZFS), it is then registered with <code>pvesm add dir</code> or <code>pvesm add zfspool</code>; otherwise it stays a host mount only."
|
||||
],
|
||||
"tipTitle": "Why UUID + nofail in /etc/fstab",
|
||||
"tipBody": "The script writes <code>UUID=… /mnt/<id> <fs> defaults,nofail 0 2</code>. UUID survives device reordering across reboots (so <code>/dev/sdc</code> becoming <code>/dev/sdd</code> does not break boot). <code>nofail</code> means that if the disk ever disappears (hardware failure, unplugged), Proxmox still boots — storage will just show as inactive until the disk comes back."
|
||||
@@ -97,7 +97,7 @@
|
||||
},
|
||||
"presets": {
|
||||
"heading": "Content-type presets",
|
||||
"intro": "Instead of a long checklist, ProxMenux offers 4 presets plus a custom option. The preset string is passed to <code>pvesm add … --content <csv></code>:",
|
||||
"intro": "ProxMenux offers three presets plus a custom option. The selected content string is passed to <code>pvesm add … --content <csv></code>:",
|
||||
"headerPreset": "Preset",
|
||||
"headerContent": "Content string",
|
||||
"headerUse": "Use case",
|
||||
@@ -115,7 +115,7 @@
|
||||
{
|
||||
"preset": "All types",
|
||||
"content": "images,backup,iso,vztmpl,snippets",
|
||||
"use": "\"Let the host decide\" — allows every content type Proxmox supports on this storage."
|
||||
"use": "The broad preset shown here enables images, backups, ISOs, LXC templates and snippets. Add other supported types, such as rootdir, through Custom if needed."
|
||||
},
|
||||
{
|
||||
"preset": "Custom",
|
||||
@@ -124,7 +124,7 @@
|
||||
}
|
||||
],
|
||||
"zfsTitle": "ZFS pool content is narrower",
|
||||
"zfsBody": "If you picked <strong>zfs</strong> as the filesystem, Proxmox only accepts <code>images</code> and <code>rootdir</code> as content types on a <code>zfspool</code> (it is block storage, not a filesystem for ISOs). The presets above will still work but Proxmox silently drops the content types it cannot use — check <code>pvesm status</code> afterwards."
|
||||
"zfsBody": "If you picked <strong>zfs</strong>, a <code>zfspool</code> supports only <code>images</code> and <code>rootdir</code>, not ISO or backup files. Use Custom to enter a supported content list. The script forwards your selection unchanged; unsupported types may make registration fail. Check <code>pvesm status</code> afterwards."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manual equivalent",
|
||||
|
||||
@@ -37,8 +37,8 @@
|
||||
"rows": [
|
||||
{
|
||||
"bit": "1 (sticky)",
|
||||
"effect": "Only the file owner can delete / rename a file.",
|
||||
"why": "Prevents CT-A from deleting files created by CT-B in the same directory."
|
||||
"effect": "Deleting or renaming a file is restricted to its owner, the directory owner or a suitably privileged process.",
|
||||
"why": "Helps prevent users with different mapped UIDs from deleting each other’s files. It does not isolate CTs that share a mapped UID or privileged root access."
|
||||
},
|
||||
{
|
||||
"bit": "777 (rwx-rwx-rwx)",
|
||||
@@ -48,7 +48,7 @@
|
||||
{
|
||||
"bit": "ACLs (default)",
|
||||
"effect": "Inherited on every newly created file / subdir.",
|
||||
"why": "The permissions apply forever — new content keeps the open profile without re-running the script."
|
||||
"why": "New content inherits the default ACLs without re-running the script. Applications can still request restrictive modes or change permissions later."
|
||||
}
|
||||
],
|
||||
"privTitle": "Privileged CTs see the same thing, just without the shift",
|
||||
|
||||
@@ -46,13 +46,13 @@
|
||||
},
|
||||
{
|
||||
"method": "<strong>Both</strong>",
|
||||
"mount": "Both paths above (two independent NFS connections to the server)",
|
||||
"mount": "Both paths above (two mount points for the same NFS export)",
|
||||
"ui": "Yes",
|
||||
"useCase": "You want UI integration AND a stable host-side path with open permissions for LXC bind-mounts. Server sees two connections from the host."
|
||||
"useCase": "UI integration plus a separate stable host path with open permissions for LXC bind mounts."
|
||||
}
|
||||
],
|
||||
"bothTitle": "\"Both\" creates two independent NFS mounts",
|
||||
"bothBody": "Marking both options runs each method independently — pvesm mounts at <code>/mnt/pve/<id></code>, fstab mounts at <code>/mnt/<path></code>. The server sees two TCP connections from the Proxmox host. This is intentional: it lets you keep the pvesm storage clean (default Proxmox options) while having a separate host-side mount with open permissions for LXC bind-mounts."
|
||||
"bothBody": "Both methods run separately: pvesm mounts at <code>/mnt/pve/<id></code> and fstab at <code>/mnt/<path></code>. This provides a Proxmox-managed mount with default options and a separate host mount for LXC bind mounts. Two mount points do not guarantee two separate TCP connections; the NFS client may reuse transport connections."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Method A — As Proxmox storage (pvesm)",
|
||||
@@ -94,7 +94,7 @@
|
||||
}
|
||||
],
|
||||
"warnTitle": "images and rootdir on NFS",
|
||||
"warnBody": "Marking <code>images</code> on an NFS storage lets Proxmox place live VM disks there. It works, but NFS latency + its lock semantics make this noticeably slower than local storage (and a network outage pauses every VM backed by that store). Marking <code>rootdir</code> means you will host LXC root filesystems over NFS, which historically has trouble with unprivileged containers (overlay / chown interactions). Prefer keeping <code>images</code> / <code>rootdir</code> on local or iSCSI storage and using NFS for <code>backup</code> / <code>iso</code> / <code>vztmpl</code>.",
|
||||
"warnBody": "Selecting <code>images</code> lets Proxmox store VM disks on NFS. Performance depends on the network, server and workload; an outage can block I/O that depends on the mount. Selecting <code>rootdir</code> stores LXC root filesystems on NFS, where unprivileged containers can encounter UID mapping, overlay and ownership limitations. Assess these requirements before placing <code>images</code> / <code>rootdir</code> there; NFS is also useful for <code>backup</code> / <code>iso</code> / <code>vztmpl</code>.",
|
||||
"result": "The result is <code>pvesm add nfs <id> --server <srv> --export <path> --content <csv></code> and Proxmox auto-mounts at <code>/mnt/pve/<id></code>."
|
||||
},
|
||||
"fstabBranch": {
|
||||
@@ -113,7 +113,7 @@
|
||||
"Attempts <code>chmod 1777</code> + <code>setfacl o::rwx</code> on the mount point (silent best-effort — only succeeds if the NFS server allows it; many NAS exports already serve world-writable paths)."
|
||||
],
|
||||
"lxcTitle": "Using the fstab mount from an LXC",
|
||||
"lxcBody": "The script prints the exact <code>pct set</code> command at the end to bind-mount the path into a container, e.g. <code>pct set <ctid> -mp0 /mnt/<path>,mp=/mnt/<ct-path>,shared=1,backup=0</code>. Or use the <mountLink>LXC Mount Manager</mountLink>, which detects the fstab mount automatically. <strong>No changes are made inside the container</strong> — for unprivileged LXCs to read/write the NFS data, the script relies on server-side world-writable export semantics (typical for Synology, TrueNAS, OMV defaults). If your NFS server squashes root or restricts perms, see Troubleshooting.",
|
||||
"lxcBody": "The script prints a <code>pct set</code> command for a bind mount, e.g. <code>pct set <ctid> -mp0 /mnt/<path>,mp=/mnt/<ct-path>,shared=1,backup=0</code>. Or use the <mountLink>LXC Mount Manager</mountLink>, which detects fstab mounts. <strong>No changes are made inside the container</strong>. Access from an unprivileged CT depends on server-side permissions for its mapped UIDs/GIDs. The script only attempts host-side permission changes; it cannot guarantee writable exports or manufacturer defaults. See Troubleshooting if access fails.",
|
||||
"noUiTitle": "The fstab mount is NOT a Proxmox storage",
|
||||
"noUiBody": "The host fstab mount is invisible to the Proxmox web UI — by design. It does not appear in <em>Datacenter > Storage</em>, you cannot select it in the VM / CT creator, and Proxmox backup jobs cannot target it. It is purely a host filesystem path. If you also want UI integration, mark <em>both</em> methods in the picker."
|
||||
},
|
||||
@@ -145,9 +145,9 @@
|
||||
"showmountTitle": "\"Failed to connect\" from showmount",
|
||||
"showmountBody": "The server refused the export-list query. Common causes: the server enforces strict client ACLs (your Proxmox IP is not on the allowed list), <code>rpcbind</code> is not running on the server, or the server exposes only NFSv4 with <code>showmount</code> disabled. The export path can still be added manually if you know it.",
|
||||
"inactiveTitle": "Storage shows as inactive in the Proxmox UI",
|
||||
"inactiveBody": "Run <em>Test NFS Connectivity</em> first — 99 % of the time this flags the exact hop that breaks (DNS, port, mount permissions). If connectivity is fine but Proxmox still flags inactive, check <code>journalctl -u pvestatd</code> on the Proxmox node; intermittent DNS or slow NFS mounts on boot can leave storages in an inactive state until <code>pvesm set <id> --disable 0</code> is re-applied.",
|
||||
"inactiveBody": "Run <em>Test NFS Connectivity</em> first: it checks that the server answers ping, that port 2049 is open and that the export list (<code>showmount -e</code>) is available. If connectivity works but storage remains inactive, inspect <code>journalctl -u pvestatd</code> and the server/export configuration. Restore the underlying connectivity or permissions first. <code>pvesm set <id> --disable 0</code> enables a disabled storage; it is not a general repair for NFS failures.",
|
||||
"lxcNoWriteTitle": "fstab mount works but unprivileged LXC can't write through a bind-mount",
|
||||
"lxcNoWriteBody": "NFS permissions are enforced server-side, not by the host. The fstab options (<code>uid=</code>, <code>file_mode=</code>) that work for CIFS do <strong>not</strong> apply to NFS. If your unprivileged LXC (root inside CT = UID 100000 on host, mapped to NFS as \"others\") cannot write, the NFS server is either squashing root or has restrictive perms. Fix on the server: change the export to <code>no_root_squash</code> if you trust the host, or set the export world-writable (Synology, TrueNAS, OMV all expose this in the UI). The script tries <code>chmod 1777</code> on the mount but that only succeeds when the server permits it.",
|
||||
"lxcNoWriteBody": "NFS access depends on server-side ownership, ACLs and squash settings. CIFS-style options such as <code>uid=</code> and <code>file_mode=</code> do <strong>not</strong> apply to NFS. With default LXC mapping, CT root becomes host UID 100000, not remote UID 0. Configure access for the actual mapped UID/GID or the server’s anonymous identity. <code>no_root_squash</code> only affects remote UID 0, so it is not a universal fix for UID 100000. The script attempts <code>chmod 1777</code> but cannot override the server’s permissions.",
|
||||
"fstabBootTitle": "fstab mount does not come up after reboot",
|
||||
"fstabBootBody": "The script adds <code>nofail,_netdev</code> so a missing share at boot does not block startup. If the mount never comes up: confirm the network is reachable (<code>ping <server></code>), check <code>journalctl -u remote-fs.target</code>, and verify the entry is valid with <code>mount -fav | grep nfs</code>. <code>mount -a</code> after boot mounts everything that is currently missing."
|
||||
},
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "What this does",
|
||||
"body": "ProxMenux offers two mount methods for any Samba share: <strong>(1) Proxmox storage</strong> via <code>pvesm add cifs</code> — visible in Datacenter > Storage, mounted at <code>/mnt/pve/<id></code>, credentials stored encrypted in <code>/etc/pve/priv/storage/<id>.pw</code>; <strong>(2) Host fstab mount</strong> at a path you pick — persistent via <code>/etc/fstab</code>, mounted with <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> so unprivileged LXC bind-mounts can write, credentials stored in a root-only <code>/etc/samba/credentials/</code> file (password never in <code>fstab</code>). You can run one method, the other, or both."
|
||||
"body": "ProxMenux offers two mount methods for a Samba share: <strong>(1) Proxmox storage</strong> via <code>pvesm add cifs</code>, visible in Datacenter > Storage and mounted at <code>/mnt/pve/<id></code>. The password is stored as plaintext in <code>/etc/pve/priv/storage/<id>.pw</code>, protected by the root-only private directory; this is access control, not encryption. <strong>(2) Host fstab mount</strong> at a chosen path, persistent through <code>/etc/fstab</code> and mounted with <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> so unprivileged LXC bind mounts can write. Its credentials are in a root-only file under <code>/etc/samba/credentials/</code>, never directly in <code>fstab</code>. Either or both methods can be used."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Opening the tool",
|
||||
@@ -41,24 +41,24 @@
|
||||
"method": "<strong>Host fstab only</strong>",
|
||||
"mountRich": "<code>/mnt/<path></code> with open uid/gid/file_mode",
|
||||
"ui": "No",
|
||||
"useCaseRich": "Bind-mounting the share into one or more LXCs <em>without</em> exposing it as a Proxmox storage. Open perms guarantee unprivileged CTs can write through the bind-mount."
|
||||
"useCaseRich": "Bind-mount the share into one or more LXCs <em>without</em> registering Proxmox storage. Open local permissions help unprivileged CTs access it, but writing still requires permission from the SMB server for the authenticated user."
|
||||
},
|
||||
{
|
||||
"method": "<strong>Both</strong>",
|
||||
"mount": "Both paths above (two independent CIFS connections to the server)",
|
||||
"mount": "Both paths above (two mount points for the same CIFS export)",
|
||||
"ui": "Yes",
|
||||
"useCase": "You want UI integration AND a stable host-side path with open permissions for LXC bind-mounts. The pvesm mount uses Proxmox defaults; the fstab mount applies the open uid/gid/file_mode separately."
|
||||
}
|
||||
],
|
||||
"bothTitle": "\"Both\" creates two independent CIFS connections",
|
||||
"bothBody": "pvesm and fstab mount the same share twice with different options. The pvesm mount at <code>/mnt/pve/<id></code> uses Proxmox defaults (no open uid/gid) — Proxmox UI is happy. The fstab mount at <code>/mnt/<path></code> uses <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> — unprivileged LXC bind-mounts to it can write. Two TCP connections to the SMB server from the same Proxmox host."
|
||||
"bothTitle": "“Both” creates two CIFS mount points",
|
||||
"bothBody": "pvesm mounts at <code>/mnt/pve/<id></code> with Proxmox defaults. fstab mounts at <code>/mnt/<path></code> with <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> to permit local access through LXC bind mounts. The SMB server still enforces the mounted user’s permissions. These are two mount points; they do not guarantee two separate TCP connections."
|
||||
},
|
||||
"pvesmBranch": {
|
||||
"heading": "Method A — As Proxmox storage (pvesm)",
|
||||
"intro": "If <em>As Proxmox storage</em> is marked, ProxMenux runs the original pvesm flow:",
|
||||
"items": [
|
||||
"<strong>Storage ID</strong> — default <code>cifs-<server-ip-with-dashes></code>. Only letters, digits, <code>-</code> and <code>_</code>.",
|
||||
"<strong>Content types</strong> — CIFS exposes <strong>6</strong> options (same as NFS minus <code>rootdir</code>, which Proxmox does not allow on CIFS because the locking semantics cannot hold a live LXC rootfs):"
|
||||
"<strong>Content types</strong> — this ProxMenux checklist offers <strong>6</strong> choices. It omits <code>rootdir</code> compared with the NFS checklist; this is a script-level choice, not a claim that every Proxmox CIFS backend version forbids LXC root filesystems:"
|
||||
],
|
||||
"headerType": "Content type",
|
||||
"headerAllows": "What it allows",
|
||||
@@ -89,16 +89,16 @@
|
||||
}
|
||||
],
|
||||
"warnTitle": "Live VM disks on CIFS",
|
||||
"warnBody": "If you tick <code>images</code>, ProxMenux pops up a warning before continuing. CIFS uses an advisory locking model that interacts badly with KVM disk operations (snapshots, live migration, I/O under contention). A backup or ISO store on CIFS is perfectly fine; a live-disk store is asking for trouble. Use NFS (or local storage) for <code>images</code> when you can.",
|
||||
"warnBody": "Selecting <code>images</code> triggers a ProxMenux warning that CIFS/SMB can cause locking issues with VM disk operations. The script recommends NFS for VM disk images but lets you continue. Backups and ISOs are common CIFS uses. Assess locking, snapshots, migration and workload requirements before using CIFS for <code>images</code>.",
|
||||
"credsTitle": "Where pvesm stores credentials",
|
||||
"credsBody": "When you use User authentication, the password is NOT written in <code>/etc/pve/storage.cfg</code>. Proxmox keeps it in <code>/etc/pve/priv/storage/<storage-id>.pw</code> — mode <code>0600</code>, owner <code>root</code>, member of the cluster sync. If you later change the password on the Samba server, use <code>pvesm set <id> --password <new></code> or remove and re-add through ProxMenux."
|
||||
"credsBody": "The password is not written in <code>/etc/pve/storage.cfg</code>. Proxmox writes plaintext credentials in <code>/etc/pve/priv/storage/<storage-id>.pw</code>, inside the private area of the cluster filesystem, readable only by <code>root</code> (mode <code>0600</code>); it is protected by access control, not by encryption. After a server password change, use <code>pvesm set <id> --password <new></code> or remove and re-add through ProxMenux."
|
||||
},
|
||||
"fstabBranch": {
|
||||
"heading": "Method B — Host fstab mount only",
|
||||
"intro": "If <em>As host fstab mount only</em> is marked, ProxMenux asks for a host mount path and persistent options, writes a root-only credentials file (User mode), then mounts and writes the entry to <code>/etc/fstab</code>:",
|
||||
"items": [
|
||||
"<strong>Host mount path</strong> — default <code>/mnt/<share-name></code>. Must be an absolute path. If something is already mounted there, or a fstab entry exists, ProxMenux offers to replace it.",
|
||||
"<strong>Mount options</strong> — pick <em>Read/Write</em> (default with <code>rw,uid=0,gid=0,file_mode=0777,dir_mode=0777,iocharset=utf8,nofail,_netdev</code>), <em>Read-only</em> (read-only variant with <code>file_mode=0555,dir_mode=0555</code>), or <em>Custom</em> (type your own option string). Open uid/gid/file_mode are always recommended for LXC bind-mount writes."
|
||||
"<strong>Mount options</strong> — choose <em>Read/Write</em> (default: <code>rw,uid=0,gid=0,file_mode=0777,dir_mode=0777,iocharset=utf8,nofail,_netdev</code>), <em>Read-only</em> (<code>file_mode=0555,dir_mode=0555</code>), or <em>Custom</em> (enter your own options). The script recommends open uid/gid/file_mode for writes through LXC bind mounts."
|
||||
],
|
||||
"credsTitle": "Credentials file (User mode)",
|
||||
"credsBody": "If you authenticated with a username + password, ProxMenux writes a root-only credentials file at <code>/etc/samba/credentials/<server>_<share>.cred</code> (mode <code>0600</code>) with <code>username=</code> and <code>password=</code> lines, and references it in the fstab entry via the <code>credentials=</code> mount option. Plain text never lands in <code>/etc/fstab</code>. For Guest mode, the option <code>guest</code> is appended instead and no credentials file is created.",
|
||||
@@ -110,7 +110,7 @@
|
||||
"Runs <code>systemctl daemon-reload</code> so systemd picks up the new fstab entry."
|
||||
],
|
||||
"lxcTitle": "Using the fstab mount from an unprivileged LXC",
|
||||
"lxcBody": "Because the CIFS client applies <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>, every file in the mount is owned by host UID 0 with mode 0777. An unprivileged LXC bind-mounting the path sees \"others\" perms on every entry (CT root = host UID 100000 = others on the host filesystem), so reads and writes succeed. <strong>No changes are made inside the container</strong> — no <code>chown</code> in the CT, no group setup, nothing modified in <code>/etc/lxc</code> beyond the single <code>mp</code> bind-mount line. The script prints the exact <code>pct set</code> command at the end, or use the <mountLink>LXC Mount Manager</mountLink> to attach the path.",
|
||||
"lxcBody": "The CIFS options <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code> open local permission checks for LXC bind mounts. Server ACLs and negotiated Unix/POSIX semantics can still affect access. <strong>No changes are made inside the container</strong>: no CT <code>chown</code>, groups or edits to <code>/etc/lxc</code>. The <code>mp</code> line is managed in Proxmox CT configuration. Use the printed <code>pct set</code> command or the <mountLink>LXC Mount Manager</mountLink>.",
|
||||
"noUiTitle": "The fstab mount is NOT a Proxmox storage",
|
||||
"noUiBody": "The host fstab mount is invisible to the Proxmox web UI — by design. It does not appear in <em>Datacenter > Storage</em>, you cannot select it in the VM / CT creator, and Proxmox backup jobs cannot target it. It is purely a host filesystem path. If you also want UI integration, mark <em>both</em> methods in the picker."
|
||||
},
|
||||
@@ -121,12 +121,12 @@
|
||||
"fstabGuestIntro": "Method B (fstab, guest auth) — no credentials file:"
|
||||
},
|
||||
"view": {
|
||||
"heading": "View configured CIFS storages",
|
||||
"body": "Lists every CIFS entry in Proxmox (<code>pvesm status | awk ''$2 == \"cifs\"''</code>) with server, share, content types, username (or <em>Guest</em>), mount path and live status. Password is <strong>never printed</strong>. <strong>Note:</strong> this view only shows pvesm-registered storages — fstab-only mounts are not listed. Check those with <code>findmnt -t cifs</code> or <code>grep cifs /etc/fstab</code>."
|
||||
"heading": "View configured CIFS storages and host mounts",
|
||||
"body": "Shows registered CIFS storages (<code>pvesm status | awk ''$2 == \"cifs\"''</code>) with server, share, content, username or <em>Guest</em>, path and status. Passwords are <strong>never printed</strong>. <strong>Note:</strong> a second section lists host fstab mounts, their options, authentication-file path and active/inactive state. For manual checks use <code>findmnt -t cifs</code> or <code>grep cifs /etc/fstab</code>."
|
||||
},
|
||||
"remove": {
|
||||
"heading": "Remove CIFS storage",
|
||||
"body": "Runs <code>pvesm remove <storage-id></code> after a confirmation that shows the server / share / content. Only the Proxmox-side registration is removed — <strong>the remote Samba server is not touched</strong>. Proxmox also deletes the paired credentials file. To remove a fstab-only mount, edit <code>/etc/fstab</code> by hand, run <code>umount <path></code>, and remove the file from <code>/etc/samba/credentials/</code>.",
|
||||
"heading": "Remove CIFS storage or a host mount",
|
||||
"body": "The removal picker offers pvesm storages and host fstab mounts. For pvesm, it runs <code>pvesm remove <storage-id></code> and Proxmox removes the paired credentials. For fstab, it attempts <code>umount <path></code>, removes the matching <code>/etc/fstab</code> entry and credentials under <code>/etc/samba/credentials/</code>, and removes an empty mount directory if possible. A failed unmount requires a manual unmount or reboot. <strong>The remote Samba server and its files are not modified</strong>.",
|
||||
"warnTitle": "Back up dependencies first",
|
||||
"warnBody": "VMs, CTs or backup jobs that reference this storage by ID will fail after removal. Move / drop those references before removing the storage."
|
||||
},
|
||||
@@ -145,7 +145,7 @@
|
||||
"sleepTitle": "\"host is down\" or storage status goes inactive at night",
|
||||
"sleepBody": "Some NAS appliances put SMB to sleep aggressively. <code>pvestatd</code> then sees the storage as inactive until the first access wakes the NAS. If this is cosmetic, nothing is broken. If it causes backup failures, disable SMB idle disconnect on the NAS or schedule backups outside the sleep window.",
|
||||
"lxcNoWriteTitle": "Unprivileged LXC bind-mount can't write to the fstab path",
|
||||
"lxcNoWriteBody": "Confirm the mount uses the open options: <code>findmnt /mnt/<path></code> should show <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>. If a Custom option string omits those, an unprivileged LXC will get permission denied (CT UIDs map to host \"others\", which without open file_mode have no write bit). Re-mount with the default RW preset or add the four options back to your custom string.",
|
||||
"lxcNoWriteBody": "Check <code>findmnt /mnt/<path></code> for the intended options, such as <code>uid=0,gid=0,file_mode=0777,dir_mode=0777</code>. Missing local write permissions can block mapped LXC UIDs. Reapply the default RW preset or adjust Custom options as needed. Also verify the mounted SMB user can write on the server and whether Unix/POSIX extensions supply server modes; open local modes cannot override server ACLs.",
|
||||
"fstabBootTitle": "fstab mount does not come up after reboot",
|
||||
"fstabBootBody": "The script adds <code>nofail,_netdev</code> so a missing share at boot does not block startup. If the mount never comes up: confirm the network is reachable (<code>ping <server></code>), check <code>journalctl -u remote-fs.target</code>, verify the credentials file still exists (<code>ls -l /etc/samba/credentials/</code>) and is readable, and try <code>mount -a</code> manually."
|
||||
},
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
},
|
||||
"privReq": {
|
||||
"title": "Privileged container requirement",
|
||||
"body": "The four <strong>LXC network sharing</strong> flows above require a <strong>privileged</strong> container — the kernel modules (<code>nfs-kernel-server</code>, <code>smbd</code>, <code>mount.nfs</code>, <code>mount.cifs</code>) need capabilities that unprivileged CTs do not expose. If you only need to share files between the host and an unprivileged CT, use the <mountLink>LXC Mount Manager</mountLink> instead — it bind-mounts from the host and adjusts permissions on the host side so the container can read and write without any kernel-module magic."
|
||||
"body": "The four <strong>LXC network sharing</strong> flows above require a <strong>privileged</strong> container. The scripts enforce this supported mode before configuring the services and mount tools (<code>nfs-kernel-server</code>, <code>smbd</code>, <code>mount.nfs</code>, <code>mount.cifs</code>). If you only need to share files between the host and an unprivileged CT, use the <mountLink>LXC Mount Manager</mountLink> instead — it bind-mounts from the host and adjusts permissions on the host side so the container can read and write without configuring these services or mount tools inside it."
|
||||
},
|
||||
"unprivExplain": {
|
||||
"title": "How ProxMenux handles unprivileged CT permissions",
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
"arrowLabel": "bind mount",
|
||||
"outro": "The host path on the left and the container path on the right can be different — for example, <code>/mnt/nas-films</code> on the host can become <code>/media/films</code> inside the container. The script adds the entry to the container config (<code>/etc/pve/lxc/<ctid>.conf</code>) using the next free <code>mpN</code> index, with two safe-defaults baked in:",
|
||||
"items": [
|
||||
"<code>shared=1</code> — tells Proxmox the data is shared storage, so it does not try to migrate the disk when you migrate the container.",
|
||||
"<code>shared=1</code> — tells Proxmox the mount uses shared data, so it does not migrate the data with the CT. This flag does not replicate data: the same path and data must already be available on the destination node.",
|
||||
"<code>backup=0</code> — excludes the bind mount from <code>vzdump</code> backups (the data lives on the host, you back it up separately)."
|
||||
]
|
||||
},
|
||||
@@ -64,7 +64,7 @@
|
||||
"idmapChangesRich": "Custom UID/GID mapping in <code>/etc/pve/lxc/<CTID>.conf</code> plus matching <code>/etc/subuid</code> + <code>/etc/subgid</code> entries on the host. CT must be restarted on every change.",
|
||||
"idmapWhenRich": "You need a <em>specific</em> UID inside the CT to map to a <em>specific</em> UID on the host (e.g. <code>media:1000</code> in the CT must own files as <code>media:1000</code> on the host so NFS doesn't squash). A more rigid setup, normally only worth it for that exact scenario.",
|
||||
"idmapTipTitle": "When you actually need lxc.idmap",
|
||||
"idmapTipBody": "If the LXC Mount Manager doesn't cover your case — typically because you need files written from inside the CT to land on the host as a specific UID/GID (NFS exports with <code>all_squash</code>, Samba shares with strict ownership, sharing a directory with a host user that has the same name as someone inside the CT) — that is the moment to add <code>lxc.idmap</code> entries by hand. The Mount Manager won't fight you: the bind-mount line it wrote is independent of any idmap configuration you add later."
|
||||
"idmapTipBody": "Use manual ID mapping when files written in the CT must appear on the host under a specific numeric UID/GID, for example to share ownership with a host user. It cannot override NFS <code>all_squash</code>; the server still decides the anonymous identity and permissions. Add <code>lxc.idmap</code> entries by hand if needed. The Mount Manager’s bind-mount line is independent of those entries."
|
||||
},
|
||||
"opening": {
|
||||
"heading": "Opening the tool",
|
||||
|
||||
@@ -56,7 +56,7 @@
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Net effect",
|
||||
"netEffectBody": "Your container always boots, even if the NFS server is offline. The first time something touches the mount path, systemd quietly mounts it. If the server is still down, that one access fails with <em>resource temporarily unavailable</em> — but nothing else in the CT is affected."
|
||||
"netEffectBody": "The NFS filesystem is mounted on <em>first access</em> rather than eagerly during boot. If the server is offline, that access may wait or fail, and services that depend on the path can be affected. Automount reduces the boot-time dependency; it does not guarantee that every CT service is unaffected by an unavailable NFS server."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manual equivalent",
|
||||
|
||||
@@ -27,9 +27,9 @@
|
||||
"heading": "The \"sharedfiles\" group convention",
|
||||
"body": "Before exporting the folder, ProxMenux creates a group called <code>sharedfiles</code> with <strong>GID 101000</strong> inside the container, adds every regular user to it, then sets the export directory to <code>root:sharedfiles</code> with mode <code>2775</code>. The <code>2</code> at the front is the SGID bit — every file or folder created inside automatically inherits the <code>sharedfiles</code> group.",
|
||||
"gidTitle": "Why GID 101000 specifically",
|
||||
"gidBody": "It maps to host GID <strong>1000</strong> when an unprivileged container reads the same file (LXC default idmap shifts everything by +100000). In the current ProxMenux flow the NFS server itself runs in a <strong>privileged</strong> CT (no shift on its side), but the convention keeps the group ID numerically consistent with unprivileged client CTs that may mount this share later. Two privileged CTs both using <code>sharedfiles</code> at GID 101000 can read / write each other's files cleanly because the GID numbers match end-to-end.",
|
||||
"remapTitle": "The script also creates 'remap_*' users — they are vestigial here",
|
||||
"remapBody": "For every regular user in the CT (and for common UIDs like 33 = www-data, 1000, 1001, 1002), the script creates a parallel <code>remap_<uid></code> user with UID = <code><uid> + 100000</code>, all members of <code>sharedfiles</code>. The <code>+100000</code> shift mimics the LXC unprivileged idmap, but since this script enforces a <strong>privileged</strong> CT (no shift), those <code>remap_*</code> users are shadow accounts with no real-world counterpart on the host. They are harmless leftovers from a more ambitious design intent. If you don't see them in <code>getent passwd</code>, nothing breaks."
|
||||
"gidBody": "With the default LXC ID map (+100000), host GID 101000 appears as GID <strong>1000</strong> inside an unprivileged CT. This server flow uses a <strong>privileged</strong> CT, where there is no shift. Two privileged CTs using <code>sharedfiles</code> at GID 101000 therefore share the same numeric group ID.",
|
||||
"remapTitle": "Legacy 'remap_*' user creation is skipped for privileged CTs",
|
||||
"remapBody": "The legacy unprivileged branch would create <code>remap_<uid></code> users with UID <code><uid> + 100000</code>, all in <code>sharedfiles</code>, for regular users and common UIDs (33, 1000, 1001, 1002). This <code>+100000</code> shift is irrelevant in the <strong>privileged</strong> CTs required by this flow, so the script skips that branch. Missing <code>remap_*</code> accounts in <code>getent passwd</code> are expected and do not indicate a failure."
|
||||
},
|
||||
"defaults": {
|
||||
"heading": "Default export options — read this first",
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
},
|
||||
"creds": {
|
||||
"heading": "Where the password lives",
|
||||
"body": "ProxMenux <strong>never stores the password in plain text</strong> in the mount command or in <code>/etc/fstab</code>. Instead it writes a credentials file inside the CT:",
|
||||
"body": "ProxMenux <strong>does not put the password in the mount command</strong> or in <code>/etc/fstab</code>. It writes a credentials file inside the CT instead. That file contains plaintext credentials protected by root-only permissions; it is not encrypted:",
|
||||
"whyTitle": "Why a separate file rather than fstab",
|
||||
"whyBody": "The CIFS module accepts <code>username=</code> / <code>password=</code> options inline in fstab, but anyone who can read <code>/etc/fstab</code> sees the password in clear. Putting credentials in a root-only file and pointing fstab at it (<code>credentials=</code>) keeps the password out of world-readable config."
|
||||
},
|
||||
@@ -85,7 +85,7 @@
|
||||
}
|
||||
],
|
||||
"netEffectTitle": "Net effect of the fstab flags",
|
||||
"netEffectBody": "Your container always boots, even if the Samba server is offline. The first time something touches the mount path, systemd quietly mounts it. If the server is still down, that one access fails with <em>resource temporarily unavailable</em> — but nothing else in the CT is affected."
|
||||
"netEffectBody": "The CIFS filesystem is mounted on <em>first access</em> rather than eagerly during boot. If the server is offline, that access may wait or fail, and services that depend on the path can be affected. Automount reduces the boot-time dependency; it does not guarantee that every CT service is unaffected by an unavailable CIFS server."
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Manual equivalent",
|
||||
|
||||
@@ -103,7 +103,7 @@
|
||||
"noShareTitle": "Client connects but cannot see the share",
|
||||
"noShareBody": "Check that <code>browseable = yes</code> is set in the share block (default for rw / ro modes; may be missing in custom). Also check the CT firewall and the Proxmox host firewall allow TCP 445 (SMB) and 139 (NetBIOS). Some Windows clients also require name resolution — try the IP directly first.",
|
||||
"authTitle": "Authentication fails (NT_STATUS_LOGON_FAILURE)",
|
||||
"authBody": "Either the wrong password (Samba passwords are <em>separate</em> from system passwords — see them with <code>pdbedit -L</code>) or the user is not in <code>valid users</code> for that share. Reset the password with <code>smbpasswd <user></code> inside the CT.",
|
||||
"authBody": "Either the password is wrong (Samba passwords are <em>separate</em> from system passwords; list Samba users with <code>pdbedit -L</code>) or the user is not in <code>valid users</code> for that share. Reset the password with <code>smbpasswd <user></code> inside the CT.",
|
||||
"groupTitle": "Files written by the client appear with wrong group on the server",
|
||||
"groupBody": "The script sets <code>force group = sharedfiles</code> in the share block, so new files should be group <code>sharedfiles</code>. If they aren't, the SGID bit on the parent directory may have been lost (someone ran <code>chmod</code> by hand). Reapply: <code>chmod 2775 /mnt/<share></code>.",
|
||||
"bothTitle": "Sharing the same folder over both NFS and Samba",
|
||||
|
||||
Reference in New Issue
Block a user