NFS volumes created using podman volume create unavailable in container #4303
Comments
openshift-ci-robot
added
the
kind/bug
|
This is not NFS specific. The |
|
I strongly suspect that your NFS invocation is incorrect, and that error is somehow being lost. I will note that Podman is invoking the I'll fix the bug here, but your NFS invocation likely still won't work as is. |
|
Found it. Stupid error on my part. Patch in a few. |
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
#4305 to fix |
|
Thank you @mheon for describing how To those in the future who might find this bug report via a Google search result, here's how to create an NFS volume using Note: This uses podman 1.6.2, and is run as root. 1. Determine the name of the NFS export you'd like to mount from your container host: 2. Create a NFS-backed volume using 3. Confirm that 4. Run a container with the volume attached: 5. Confirm you can see and write to your NFS share via the volume you just created: |
|
Looks like this would be a nice addition to the man page. @toddhpoole Would you like to open a PR to the man page to add your example. |
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
I'll take the docs changes |
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
command.Start() just starts the command. That catches some errors, but the nasty ones - bad options and similar - happen when the command runs. Use CombinedOutput() instead - it waits for the command to exit, and thus catches non-0 exit of the `mount` command (invalid options, for example). STDERR from the `mount` command is directly used, which isn't necessarily the best, but we can't really get much more info on what went wrong. Fixes containers#4303 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
|
Are the docs updated? I've been looking into the official docs http://docs.podman.io/en/latest/search.html?q=nfs&check_keywords=yes&area=default and man pages and there are no comments about NFS. |
|
@mheon those docs changes seem to have never made it in :) |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
After filing bug reports #4249, #4248, and #4247, and seeing all 3 resolved by the release of 1.6.2, we resumed trying to use
podman volume createto create and mount NFS-backed volumes as originally announced in 1.6.1.After re-creating an NFS-backed volume using 1.6.2, we're still unable to see the contents of that volume from within our containers.
Documentation covering NFS volumes is non-existent, so we cannot tell if this is user error or broken code. As a part of resolving this issue, please consider adding NFS test cases to your build pipeline and expanding the Examples section of
podman-volume-create.1.mdand/orpodman-run.1.mdwith more examples, including NFS ones.Steps to reproduce the issue:
podmanis aware of the volume.Describe the results you received:
The NFS share is not mounted nor accessible from within the container.
Describe the results you expected:
The NFS share is mounted and accessible from within the container.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Additional environment details (AWS, VirtualBox, physical, etc.):
Fresh minimal install of Fedora 30 with:
yum -y install vim nfs-utils buildahyum -y distro-sync --enablerepo=updates-testing podmanExports are visible to host:
Exports can be mounted outside of podman using
mount 192.168.2.126:/exports/test /mnt/testso it does not appear to be an issue with the NFS server.The text was updated successfully, but these errors were encountered: