Fixing NFS Permissions In Rootless Podman Containers

Dec 11, 2025 by Andrew McMorgan 53 views

Hey guys, ever found yourselves staring at a Permission denied error when trying to write to an NFS share from your rootless Podman container, even though the owner and ACLs look absolutely fine? Trust me, you're not alone. This is one of those incredibly frustrating issues that can make you question your sanity. You've checked everything, the user should have access, but the system just flat-out says "nope." We've all been there, and it’s a super annoying hurdle when you're trying to leverage the power and security of rootless containers with network-attached storage.

Today, we’re going to deep dive into this specific problem, dissecting why you might be getting those stubborn permission errors, especially when moving directories around. We'll explore the nuances of NFS4, ACLs, and how user ID mapping in rootless Podman interacts with your NFS server. The goal? To equip you with the knowledge and troubleshooting steps to conquer these elusive permission denied messages once and for all. So, grab a coffee, and let's unravel this mystery together, making your rootless Podman containers play nicely with NFS shares.

The Rootless Podman & NFS Headache: A Common Scenario

Alright, let’s set the scene, guys. You’re all about that rootless Podman life – it's more secure, keeps your host clean, and generally makes you feel like a Linux wizard. You've got this cool application running in a container, and it needs access to a shared storage solution, so naturally, you turn to NFS4. You set up your NFS mount, carefully configuring it to ensure your files are accessible. You even go the extra mile, checking that the owner and Access Control Lists (ACLs) on the NFS share match the user inside your container, or at least the user that Podman maps to on the host. Everything seems to line up perfectly. You can read files, you can even create new files or move directories from outside the NFS share into it without a hitch. Life is good, right?

But then, the nightmare begins: you try to perform an operation within the NFS share itself, like moving an existing directory from one location to another inside the same NFS mount, and BAM! Permission denied. It's infuriating because you just created something else there, and the permissions look identical. This specific scenario, where creating or moving into NFS works, but moving within fails, is a classic symptom of deeper issues related to how NFS handles metadata, atomic operations, and, crucially, how user IDs are mapped across your container, host, and the NFS server. We're talking about a multi-layered puzzle involving idmapd on both ends, potentially differing subuid and subgid mappings, and the subtle differences in what operations like mv truly entail on an NFS filesystem versus a local one. Understanding these intricacies is key to unlocking why your seemingly correct permissions are still causing such a ruckus. This isn't just about a simple chmod; it's about the entire ecosystem of user and group identification from your rootless container all the way to the NFS server, and how those identities are translated and respected (or not) during various file operations. We need to consider the NFS server's export options, the client's mounting options, and the very nature of rootless container user namespace remapping. This seemingly simple permission error often hides a complex interplay of network filesystem protocols and containerization technologies, demanding a comprehensive troubleshooting approach that goes beyond surface-level permission checks.

Diving Deep into NFS4, ACLs, and User Mappings

Alright, let's get into the nitty-gritty of what's actually going on under the hood, because understanding these core components is crucial for troubleshooting. We're talking about the fundamental building blocks that govern permissions and access when you're dealing with NFS4, especially in a containerized environment. This isn't just about knowing what an NFS share is; it's about understanding how it identifies users, manages access, and translates permissions across different systems. The magic (or often, the headache) happens in the interaction between your client machine (running Podman), the NFS server, and the NFS protocol itself, which has evolved quite a bit with version 4. So, let’s peel back these layers.

Understanding NFS4 and its Permissions Model

NFS version 4 is a beast compared to its predecessors, guys. It introduced a more robust security model, relying heavily on user IDs and group IDs, similar to local Unix filesystems, but with a critical difference: network transparency. This means the NFS server needs a way to understand who a user is, even if that user's ID on the client doesn't directly exist on the server. This is where idmapd comes into play. idmapd (ID mapper daemon) and nfsidmap are essential services responsible for mapping local Unix UIDs/GIDs to NFSv4-specific string-based identities (like user@domain) and back again. If idmapd isn't running correctly, or if its configuration (/etc/idmapd.conf) is off on either your client (Podman host) or your NFS server, then the server might receive an anonymous user ID or an incorrectly mapped ID. This leads to access denied errors, even if a user with that same numeric ID does exist on the server. The importance of a consistent Domain setting in idmapd.conf across all participating machines cannot be overstated. A mismatch here is a prime suspect for permission woes. Furthermore, NFS4 permissions also incorporate a concept closer to Windows-style ACLs, which offers more granular control than traditional Unix rwx bits. These extended ACLs can either be a savior, allowing precise access control, or another layer of complexity if misconfigured. The server might be interpreting permissions based on an ACL entry that’s not visible or correctly understood by the client, especially when the idmapd translation isn't perfect. This intricate dance of ID mapping and permission interpretation is what often trips us up, creating a seemingly impenetrable wall of "permission denied" messages despite our best efforts to align numeric IDs.

The Role of ACLs (Access Control Lists)

Let’s talk about ACLs, short for Access Control Lists. For those of you who've worked with more advanced file permissions, ACLs are like the super-powered older sibling to your traditional Unix rwx permissions. Instead of just owner, group, and others, ACLs allow for much more granular control, letting you specify permissions for multiple specific users and groups on a single file or directory. This is particularly powerful in mixed environments or when you need fine-tuned access. However, with great power comes great debugging responsibility! A common issue with NFS and ACLs is when they're either not understood correctly by the NFS server, or there's a mismatch in how the client and server interpret them, perhaps due to different NFS client/server versions or underlying filesystem capabilities. You might see a chmod 777 on a directory, and it still denies access because an ACL entry is overriding or restricting it for the specific user/group. Commands like nfs4_setfacl and nfs4_getfacl become your best friends here. You need to inspect the ACLs on the NFS share from both the client and server perspective, ensuring they align with your expectations for the user attempting the operation. An incorrectly applied deny ACL entry, or one that's not being translated correctly through idmapd, can effectively block access, regardless of what the basic ls -l output might suggest. These nuanced permissions can be tricky because ls -l won't show you the full picture; it only gives you a hint that an ACL is present (often with a + symbol after the permission string). So, always dig deeper with nfs4_getfacl to truly understand what's at play. The interaction between traditional Unix permissions and NFS4 ACLs, combined with the ID mapping, forms a complex security matrix that needs to be correctly configured and consistently interpreted across all systems involved to avoid permission-related frustrations.

User and Group ID Mapping: The Hidden Culprit

Now, this is where things get really interesting, especially with rootless Podman. When you run a rootless container, the user inside the container isn't actually root on the host. Instead, Podman uses user namespaces to map the container's UIDs/GIDs to a range of unprivileged UIDs/GIDs on the host. These mappings are defined in /etc/subuid and /etc/subgid. For example, root inside your container might map to 100000 on your host machine. When your container accesses an NFS share, the NFS client on your host machine makes the request to the NFS server using the host's mapped UID/GID (e.g., 100000), not the container's internal UID/GID (e.g., 0).

The crucial point here, guys, is that the NFS server then receives this host-mapped UID/GID (e.g., 100000) and tries to map it to an actual user/group on the server itself using its own idmapd configuration. If the NFS server doesn't have a corresponding idmapd rule or a user with that specific ID, it might default to the anonuid and anongid (anonymous user/group) specified in its /etc/exports file, or simply deny access. This often happens if you're not explicitly telling idmapd on the server to map that 100000 back to a known user like myuser@mydomain. So, even if the file on the NFS share is owned by myuser (UID 1000), and root in your container thinks it's myuser through subuid mapping, the NFS server might see an anonymous user trying to access the file because the idmapd chain is broken somewhere. This intricate dance of identity translation – from container, to host, to NFS client, to NFS server's idmapd – is incredibly prone to misconfiguration and is often the root cause of those inexplicable Permission denied messages. Ensure your idmapd domain is consistent across all systems and that subuid/subgid ranges are correctly understood by your NFS server's user mapping configuration. This requires a careful audit of /etc/idmapd.conf on both client and server, along with understanding the user mapping rules Podman establishes for your rootless containers. Without this precise mapping, the NFS server simply can't associate the incoming request with the correct permissions, leading to frustrating access denials.

Unpacking the "Permission Denied" Mystery in Podman

Alright, this is the heart of our problem, guys: that frustrating moment when you can create files, but you can't move them around within the NFS share. It feels like a paradox, doesn't it? Let’s dissect this specific behavior, because it holds crucial clues about what's truly going on with your permissions, your rootless Podman setup, and the underlying NFS protocol. It's often not a simple matter of read or write access, but rather the intricacies of specific filesystem operations and how NFS handles them, especially when combined with user ID remapping.

Why Moving Files Into NFS Works, But Moving Within Doesn't

This specific symptom is a major red flag and points to a fundamental difference in how various file operations are handled by the NFS protocol. When you move a directory that is not in NFS into NFS (e.g., mv /local/path/temp_dir /nfs/share/), what's typically happening is a series of create operations. The mv command essentially copies the files and directories from the source to the destination, and then, if successful, deletes the original. The crucial part here is the creation aspect. If the effective user (which, remember, is your host-mapped UID/GID from your rootless Podman container) has write and execute permissions on the target parent directory (/nfs/share/), then it can create new files and subdirectories there. The ownership and permissions for these newly created items will typically be set based on the umask of the user and the default NFS export options.

However, when you try to move a directory from one location to another within the NFS share (e.g., mv /nfs/share/old_dir /nfs/share/new_dir), you're often attempting an atomic rename operation or, at minimum, an operation that requires more than just simple write permission on the destination. On many filesystems, especially network ones like NFS, an mv within the same filesystem often translates to a low-level rename() system call. This rename() operation typically requires write permissions on the parent directories of both the source and destination paths. More specifically, to rename old_dir to new_dir, the user needs write permission on the parent directory of old_dir to remove its entry, and write permission on the parent directory of new_dir to create the new entry. If old_dir and new_dir are siblings within /nfs/share/, then the user needs write permission on /nfs/share/ itself. But here’s the kicker: sometimes, depending on the NFS server's configuration and the underlying filesystem, rename() can also implicitly require delete permissions on the source entry or modify permissions on the parent directory that houses the original item. Your host-mapped UID/GID from Podman might have general write access to create new entries, but it might lack the specific delete or modify permissions on existing entries or their parent directories needed for an atomic rename operation. This distinction is subtle but critical. It’s not just about creating; it's about altering the directory structure itself, which demands a slightly different set of permissions than simply adding new files. This could be due to specific ACLs, server export options like root_squash or all_squash subtly interfering, or an incomplete idmapd translation for the specific rename operation context.

Common Misconfigurations Leading to Denials

Many common misconfigurations can lead to these head-scratching Permission denied errors. Firstly, incorrect idmapd configuration is a prime suspect. If the Domain setting in /etc/idmapd.conf on your client or server doesn't match, or if idmapd isn't running or restarting properly, UIDs and GIDs won't be correctly translated. The NFS server might then see requests coming from an anonymous user (anonuid/anongid) even if you're root inside your container, because that internal root maps to a host UID, which then fails to map properly on the server.

Secondly, mismatched UIDs/GIDs between your container, host, and NFS server are crucial. Your rootless container's root (UID 0) gets mapped to a subuid on your host (e.g., 100000). If the NFS server doesn't recognize 100000 as a valid user, or doesn't have idmapd configured to translate it to a known user on the server, then access is denied. This problem is exacerbated when anonuid and anongid are configured on the NFS server's export options. If your server is squashing all requests to an anonymous user, and that anonymous user doesn't have the necessary permissions, you're stuck. You might have anonuid=65534 (nobody) in your /etc/exports, and if the NFS share doesn't grant permissions to nobody, then any operation that gets squashed will fail.

Thirdly, the NFS server export options in /etc/exports are critical. Options like rw (read/write), sync, no_subtree_check, and especially no_root_squash or all_squash can dramatically affect permissions. If root_squash is active (which it often is by default for security), any requests coming from UID 0 (or a mapped root) will be squashed to nobody, potentially causing issues. If all_squash is active, all requests are mapped to anonuid/anongid, which is great for anonymous access but terrible if you need specific user permissions. For rootless containers, you often need to carefully manage this to ensure the mapped host UID is handled correctly. Lastly, don't forget about SELinux or AppArmor on your client host. These security modules can interfere with NFS mounts or container access, even if your file permissions are perfect. A quick check of audit.log or disabling SELinux temporarily can sometimes reveal if these are the hidden culprits, blocking your container from interacting correctly with the mounted NFS share. Any of these misconfigurations, alone or in combination, can lead to the vexing "permission denied" errors that seem to defy logic, especially when some operations work and others don't. It's truly a multi-pronged attack on your sanity, but by systematically checking these areas, you can pinpoint the exact cause.

Your Troubleshooting Toolkit: Getting NFS to Play Nice

Alright, guys, enough talk about the problem – let's get down to business with the solutions! When you're facing those stubborn NFS permission denied errors in your rootless Podman containers, you need a systematic approach. It's like being a detective, gathering clues from different systems to piece together the full picture. We're going to arm you with a comprehensive toolkit to identify and rectify the common pitfalls that plague NFS setups, especially with the added complexity of rootless containerization. Don't worry, we'll walk through each step with practical commands and explanations. This isn't just about throwing commands at the wall; it's about understanding why you're running them and what insights they provide into the intricate dance of IDs and permissions across your client, container, and NFS server. So, let’s roll up our sleeves and dive into some serious diagnostics to make that NFS share cooperate.

Verifying User Mappings and IDs

This is perhaps the most critical step, guys. The entire permission structure in NFSv4 hinges on correct user and group ID mapping. You need to check IDs at three levels: inside the container, on the Podman host, and on the NFS server.

Inside the Container: Start by running podman exec -it <container_name> id -u and podman exec -it <container_name> id -g. This will show you the UIDs and GIDs as seen by the application inside the container. For rootless containers, root will typically be 0.
On the Podman Host: Now, find out how that container user maps to the host. The /etc/subuid and /etc/subgid files define the ranges. For your regular user (let's say youruser with UID 1000), these files might contain youruser:100000:65536, meaning UIDs starting from 100000 are allocated for sub-containers. So, root (UID 0) in the container maps to 100000 on the host. You can confirm your host's UID/GID with id -u and id -g as your normal user. For more advanced idmapd debugging on the client, nfsidmap -l will list known mappings, and rpc.idmapd -p will show you idmapd's status. Check /etc/idmapd.conf for the Domain setting; it must match the NFS server.
On the NFS Server: This is where the rubber meets the road. The NFS server will receive the host's mapped UID/GID (e.g., 100000). You need to ensure the NFS server's idmapd can correctly translate this 100000 back to a recognizable user. Check /etc/idmapd.conf on the server for the Domain setting – again, it must match the client. Also, look at the NFS server's /etc/passwd and /etc/group to see if there's a user or group that 100000 should map to. If idmapd isn't translating it, the server might default to nobody (UID 65534). You can often see idmapd logs in journalctl -u rpc-idmapd or syslog to catch translation errors. The key takeaway here is absolute consistency in Domain settings and transparent mapping of UIDs/GIDs across all three layers. A single mismatch or misconfigured daemon will break the entire chain, leading to denied access. Don't skip this step; it's the foundation of secure and functional NFS access.

Checking NFS Server Export Options

Your NFS server’s /etc/exports file is like the rulebook for what clients can do. This is a crucial place to check for misconfigurations. Open up /etc/exports on your NFS server and look at the line(s) defining the share your Podman container is using.

Here are some options to pay close attention to:

rw (read/write): Make sure this is present. Without it, you can't write, simple as that.
sync: Ensures that writes are committed to stable storage before replying. Can impact performance, but ensures data integrity.
no_subtree_check: Often recommended for performance and to avoid some weird permission issues. It disables subtree checking, which can sometimes interfere with operations.
no_root_squash: This is a big one. By default, NFS servers often use root_squash, which maps requests from root (UID 0) on the client to nobody (UID 65534) on the server. If your container's mapped root (e.g., UID 100000 on the host) needs actual root-like permissions on the NFS share, and the server squashes it, you'll get permission denied. no_root_squash prevents this squashing for UID 0 (and only UID 0), but use it very carefully as it has significant security implications. For rootless Podman, remember that the host's subuid (e.g., 100000) is what the server sees, not the container's 0 directly. So, no_root_squash might not apply to your mapped user anyway.
all_squash: This option maps all client UIDs/GIDs to the anonuid/anongid specified. If you have this, and anonuid/anongid don't have write permissions, then nothing will work. This is commonly used for public, read-only shares.
anonuid=<UID> and anongid=<GID>: These specify the user and group ID to which root_squash or all_squash users are mapped. Ensure these UIDs/GIDs on the NFS server have the appropriate permissions on the shared directory.

After making any changes to /etc/exports, remember to run exportfs -ra on the server and potentially restart the NFS services (systemctl restart nfs-server or nfs-kernel-server). Incorrect export options are a frequent source of access issues, especially when you think you have permissions but the server's rules are silently overriding them. It's crucial to ensure these options align with the level of access you intend to grant to your Podman client. If you're using no_root_squash or all_squash, make absolutely certain that your anonuid/anongid (if used) are valid and have the necessary permissions on the NFS share.

Debugging Permissions with `nfs4_getfacl` and `ls -ln`

Simply running ls -l often doesn't give you the full picture, especially with NFSv4 and ACLs. You need more detailed tools, guys.

ls -ln <nfs_mount_point>: The -n flag forces ls to display numeric UIDs and GIDs instead of user/group names. This is incredibly useful because it shows you exactly what numeric ID owns a file or directory on the NFS share. Compare these UIDs/GIDs to the mapped UIDs/GIDs on your Podman host (from /etc/subuid and id -u) and what idmapd on the server is configured to translate. If you see files owned by 65534 (nobody) or another unexpected numeric ID, it's a strong indicator that idmapd is failing to map your user, or root_squash/all_squash is in effect.
nfs4_getfacl <file_or_dir>: This command is your best friend for understanding NFSv4 ACLs. It will display the detailed Access Control List for a given file or directory on the NFS share. You might find explicit deny entries for certain users or groups, or entries that grant permissions only to specific UIDs/GIDs that aren't aligning with your Podman-mapped user. For example, if you see an entry like A::OWNER@:rwaDxtTnNcCoyV (meaning full access to the owner) but OWNER@ isn't translating to your user, or there's another A::GROUP@:deny for a group your user belongs to, that's your problem. Pay close attention to the who field (e.g., OWNER@, GROUP@, or specific users/groups) and the permission flags. Sometimes, a seemingly correct ls -l output can be misleading due to an underlying ACL that’s silently denying access. This command is crucial for uncovering those hidden permission rules that can block operations like moving or deleting files, especially when simpler rwx bits seem sufficient. By meticulously comparing the numeric IDs and ACLs, you can identify precisely where the permission chain is breaking.

Podman Mount Options and Troubleshooting

Your Podman command itself can hold clues and solutions, guys. The way you mount the NFS volume into your container is critical.

SELinux Context (:z or :Z): If you're running with SELinux enabled on your host, an incorrect context can prevent your container from accessing the mounted volume. Using :z tells Podman to label the volume mount with a shared content label, allowing all containers to read/write. :Z labels it with a private, unshared label. For most NFS mounts, :z is a good starting point if SELinux is interfering. You'd add this to your mount argument: --mount type=bind,source=/nfs/share,target=/app/data,z.
Ensuring Correct Mount Syntax: Double-check your Podman mount command (-v or --mount). Simple typos or incorrect paths can lead to problems. Ensure the source path on the host (/nfs/share) is the actual NFS mount point.
Checking Podman Logs: Sometimes, the container runtime itself will provide hints. Use podman logs <container_name> to see if there are any specific errors during startup or when the application tries to access the volume. These might not always be explicit permission errors, but could point to issues with the mount itself.
Running with a Debug Shell: The ultimate test is often to run your container with an interactive shell and manually try the problematic operations. podman run -it --rm --name debug_nfs --mount type=bind,source=/nfs/share,target=/app/data,z your_image /bin/bash Once inside the container, try ls -ln /app/data, touch /app/data/testfile, mv /app/data/existing_dir /app/data/new_dir. This allows you to isolate the problem within the container's environment and see the exact error message in real-time. This interactive debugging approach can save you hours by letting you experiment directly with file operations, bypassing the application logic and focusing solely on the filesystem interaction. By observing the immediate feedback from the shell, you can pinpoint whether the issue lies with file creation, deletion, or renaming, which is critical for understanding the underlying permission requirement that’s currently unmet.

Best Practices for Robust Rootless Podman NFS Mounts

Alright, guys, you've battled the Permission denied beast, and hopefully, you're on your way to victory. But beyond just fixing the immediate problem, let's talk about some best practices to ensure your rootless Podman containers play nicely with NFS for the long haul. This isn't just about troubleshooting; it's about building a resilient and secure infrastructure from the ground up, minimizing future headaches and ensuring smooth operations. By adopting these strategies, you can preemptively address many of the common issues we've discussed, making your life a whole lot easier when dealing with distributed storage and containerized applications. Consistency and careful configuration are your allies here.

Consistent UID/GID Across Environments: This is paramount. Where possible, strive for consistent UIDs and GIDs for your application users across your NFS server, Podman host, and even within your container image (if not relying solely on subuid/subgid mapping). If idmapd needs to translate 100000 from the client to myuser (UID 1000) on the server, ensure myuser actually exists with UID 1000 and idmapd is explicitly configured to do that mapping. Hardcoding specific UIDs/GIDs in your container's Dockerfile (e.g., USER 1000) and ensuring those map cleanly can simplify things dramatically, though it might reduce the flexibility of true rootless operation if not carefully managed with subuid.
Use idmapd Effectively on Both Client and Server: Don't just enable idmapd; configure it correctly. Ensure the Domain in /etc/idmapd.conf is identical on all NFS clients and servers. This allows NFSv4 to correctly translate numeric UIDs/GIDs to canonical user@domain strings and back. If idmapd isn't running or configured, you'll constantly run into nobody issues or outright denials. Regularly check journalctl -u rpc-idmapd for errors.
Careful Configuration of NFS Export Options: Review your /etc/exports file on the NFS server with a critical eye. Avoid all_squash unless you truly intend for completely anonymous access. If you need specific user permissions, ensure root_squash isn't inadvertently squashing your legitimate mapped UIDs to nobody. For cases where your rootless container's mapped user must have specific powerful access, you might need to use no_root_squash (with extreme caution and understanding of its security implications) or create specific user mappings on the server with corresponding permissions.
Understand subuid/subgid for Rootless Containers: Remember that the UID/GID seen by the NFS server is the subuid/subgid mapped user on your Podman host, not the container's internal UID/GID. Design your NFS permissions to reflect these host-mapped IDs. You might need to configure your NFS server's idmapd to specifically map these ranges (e.g., 100000-165535) to a single, trusted user or group that has the necessary permissions on the NFS share. This level of understanding is crucial for bridging the gap between container isolation and network filesystem access.
Test Permissions Thoroughly, Don't Assume: After any change to NFS exports, idmapd.conf, or Podman mount commands, test everything. Don't just assume it works. Test file creation, reading, writing, moving within the share, and deleting from both inside and outside the container. Use the debug shell technique we discussed to confirm operations are working as expected. Many issues only surface during specific operations, like the mv within the share that started this whole discussion.
Consider Named Volumes with Podman for Better Management: For more persistent and managed storage, especially with NFS, explore Podman's named volumes. You can define a volume with a specific driver (e.g., nfs if supported directly by a plugin, or simply bind-mount a host directory that's an NFS mount) and let Podman handle some of the lifecycle. This can sometimes provide a cleaner abstraction and allow for more consistent mounting across different containers or hosts. It helps abstract away the raw --mount commands and can be easier to manage in a CI/CD pipeline or orchestration setup, especially if you need to pass specific NFS mount options consistently.

Wrapping It Up: Conquering NFS Permissions

So there you have it, guys! We've taken a pretty deep dive into the sometimes-confounding world of NFS permissions when working with rootless Podman containers. It’s clear that a Permission denied error, especially when things seem right, is rarely a simple issue. More often, it's a symptom of an intricate dance involving idmapd misconfigurations, subuid/subgid mapping complexities, subtle NFS export option interactions, and the nuanced behavior of file operations like mv on a network filesystem. We’ve explored why moving files into an NFS share might work, while moving within it might not, highlighting the different permissions required for creation versus atomic rename operations.

The key takeaway here is systematic troubleshooting and deep understanding of each layer. From verifying UID/GID mappings across your container, host, and NFS server to meticulously checking idmapd configurations, scrutinizing NFS export options, and leveraging powerful tools like nfs4_getfacl and ls -ln, you now have a comprehensive toolkit. Remember, consistency in your idmapd domain is non-negotiable, and understanding how root_squash or all_squash can affect your mapped rootless container user is absolutely crucial. By following the best practices we've outlined – ensuring consistent IDs, configuring idmapd effectively, carefully managing export options, and rigorously testing – you're well-equipped to tame even the most stubborn NFS permission issues. Keep at it, stay curious, and you'll be deploying robust, secure, and fully functional rootless Podman containers with NFS shares in no time. Happy containerizing, and may your permissions always be granted!