RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1815991 - can't update named volume path
Summary: can't update named volume path
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: podman
Version: 8.1
Hardware: All
OS: All
unspecified
high
Target Milestone: rc
: 8.2
Assignee: Jindrich Novy
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1186913 1793607
TreeView+ depends on / blocked
 
Reported: 2020-03-23 05:45 UTC by jajeon
Modified: 2023-09-07 22:30 UTC (History)
10 users (show)

Fixed In Version: podman-1.9.3 and newer
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-21 15:31:55 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4964471 0 None None None 2020-04-06 07:18:34 UTC
Red Hat Product Errata RHSA-2020:3053 0 None None None 2020-07-21 15:32:38 UTC

Comment 1 Daniel Walsh 2020-03-23 12:52:48 UTC
The volume path can only be changed on initialization of the storage.

You can reinitialize storage with

podman system reset

But this will remove all of your containers and storage.

Comment 2 Matthew Heon 2020-03-23 13:28:19 UTC
To expand a bit: This is a protection to prevent accidental corruption of Podman's state. If there were any volumes present when this directory was changed, the volumes (and all their contents) would be lost as we changed to the new directory, and any containers using them could be pointing to the wrong directory. We require that changes to core Podman paths be done in company with a reset of Podman's state to ensure that such things do not happen.

Comment 3 jajeon 2020-03-24 02:10:07 UTC
There is there no "reset" command available from podman.

># podman system reset
>Error: unrecognized command `podman system reset`
>Try 'podman system --help' for more information.

Is there any other way to change named volume path?

If this is to prevent accidental corruption, what is the reason of having configuration file?
Also, if that's the reason, why allowing anonymous volume change by just modifying configuration file?

-- for root user
># grep root /etc/containers/storage.conf | grep -v '#'
>runroot = "/vol1"
>graphroot = "/vol1"

-- for rootless
>$ grep root ~/.config/containers/storage.conf 
>  runroot = "/tmp/run-1001"
>  graphroot = "/home/t1/test"

Comment 4 Daniel Walsh 2020-03-24 10:00:13 UTC
Ok the version of podman you have is before that was added.

rm -rf ~/.local/share/containers ~/.config/containers

Should be close the the equivalent.

Comment 5 jajeon 2020-03-24 13:38:47 UTC
I think path that you provided is for rootless user.

Customer is trying to update "volume_path" from /usr/share/containers/libpod.conf which is "root" user.

Comment 6 Matthew Heon 2020-03-24 13:48:09 UTC
The directories would be /var/lib/containers/storage and /var/run/libpod then.

Addressing earlier comments - the configuration file can be used for initial configuration of critical paths, but unfortunately cannot be used to change said paths once Podman has been run and containers created without a serious risk of non-intuitive breakage of containers, hence the error you've seen here. There is a potential improvement where we could allow rewrite of these paths if and only if no containers, pods, and volumes were present on the host (as the user running Podman, at least) which would eliminate the need for complete removal of directories of `podman system reset`

Comment 7 jajeon 2020-03-25 05:07:43 UTC
I was able to update "volume_path" after removing bolt_state.db file.
Could you check this is good enough or I need to remove all the files under /var/lib/containers/storage and /var/run/libpod.

# podman images
Error: Could not get runtime: database volume path "/var/lib/containers/storage/volumes" does not match our volume path "/test": database configuration mismatch

# rm /var/lib/containers/storage/libpod/bolt_state.db
rm: remove regular file '/var/lib/containers/storage/libpod/bolt_state.db'? y

# podman images
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE

# podman info |grep -i vol
  VolumePath: /test


Can you let me know when "podman system reset" will be available?

I was able to find the github PR as below.
https://github.com/containers/libpod/pull/4558

However, version that I'm using is the latest available version from RHEL8 repository.
https://access.redhat.com/downloads/content/rhel---8/x86_64/7441/podman/1.6.4-2.module+el8.1.1+5363+bf8ff1af/x86_64/fd431d51/package

Comment 8 Daniel Walsh 2020-03-25 10:56:29 UTC
We release new versions of Podman every 12 weeks.  The 1.6.4 is being released now for RHEL8.2  Which means we will update the next release in the summer.
RHEL 8.2.1 release.  Will probably be podman 1.8.2 or newer.

Comment 9 Matthew Heon 2020-03-25 13:13:22 UTC
Removing the boltdb database is sufficient so long as there are no containers and no volumes on the system when it is removed. Otherwise, you will end up with shadow containers/volumes that prevent the names of the old volumes and containers from being reused, and that cannot be easily removed.

Comment 10 Daniel Walsh 2020-06-03 14:11:54 UTC
Fixed in rhel8.2.1 release I believe.

Comment 13 Tom Sweeney 2020-06-03 18:03:33 UTC
Assigning to Jindrich just in case there's any packaging needs, but as this was in Podman 1.14.9, I don't believe there's anything further necessary.

Comment 18 Joy Pu 2020-06-16 15:01:20 UTC
Test with podman-1.9.3-2.module+el8.2.1+6867+366c07d6.x86_64. "podman system reset" makes the volume path be update based on the libpod.conf. So set this to verified. Details:
# podman system reset

WARNING! This will remove:
        - all containers
        - all pods
        - all images
        - all build cache
Are you sure you want to continue? [y/N] y
# podman info |grep volume
  volumePath: /test

Comment 20 errata-xmlrpc 2020-07-21 15:31:55 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3053


Note You need to log in before you can comment on or make changes to this bug.