You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having migrated over from Docker to Podman this year, I have been teaching reproducible computing/Python to students on a mix of Macs and PCs. They tend to set up their working iPython notebooks on their host machines in all sorts of different places so we've been using -v $(pwd):/home/jovyan/work to connect the host directory to the JupyterLab container. The image is built on top of quay.io/jupyter/minimal-notebook:notebook-7.4.4 and the full build file is here though that's only for completeness as I don't think it's relevant.
My own migration went seamlessly (well, until later), but about 25% of students using the macOS were unable to use bindmounts unless they set the permissions on the host directory and all subfolders to 777 (and 666 for all files) which is hardly desirable. I couldn't reproduce this until I rebuilt my VM this morning at which point I had the exact same problem.
I went down all sorts of paths and the only approach that seemed to have any effect was adding --userns=keep-id:gid=20 to the run command as that adds the jovyan user to a group with the same GID as the staff group in macOS. Adding uid=501 to remap the user has no effect (for fairly obvious reasons, I assume). This at least changed the permissions required for write access from 777 to 770/775 for folders and 666 to 664/0 so that was an improvement.
However, I suddenly realised that there were two ways to configure the machine: with Apple's hypervisor or with the newer default Krunkit. I rebuilt the machine for the nth time but this time forcing it to use applehv (export CONTAINERS_MACHINE_PROVIDER="applehv"). Suddenly bindmounts worked again with zero permissions issues.
I've now tested this by initialising a second VM with the same specs but using the newer libKrun default and have confirmed that this VM does not allow me to successfully mount host directories that are writeable/accessible as if by the user running podman.
I don't believe it's anything specific to my image, but just in case here's the command that works with hypervisor and not with libKrun:
As a final step I did also try to ensure that it wasn't a missing library by following an apparent suggestion to:
brew tap slp/krunkit
brew install krunkit
That didn't fix anything so I've now brew uninstalled it.
Am I missing something? I will confess that the container <-> VM <-> host UID/GID mapping element is really at the limit of my understanding but I do feel like I chased down every viable lead for solving this with libKrun and kept having to come back to using Apple Hypervisor as the only way forward.
Suggestions gratefully received. This discussion builds on an exchange on BlueSky which was really helpful but a little constrained for exploring the issue since I couldn't give a full background or really understand the options.
Relevant Hardware/Software Information
Mac:
MBP 14" 2023
M2 Max
macOS Sequoia 15.7.2 (was waiting until end of term to upgrade)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Having migrated over from Docker to Podman this year, I have been teaching reproducible computing/Python to students on a mix of Macs and PCs. They tend to set up their working iPython notebooks on their host machines in all sorts of different places so we've been using
-v $(pwd):/home/jovyan/workto connect the host directory to the JupyterLab container. The image is built on top ofquay.io/jupyter/minimal-notebook:notebook-7.4.4and the full build file is here though that's only for completeness as I don't think it's relevant.My own migration went seamlessly (well, until later), but about 25% of students using the macOS were unable to use bindmounts unless they set the permissions on the host directory and all subfolders to 777 (and 666 for all files) which is hardly desirable. I couldn't reproduce this until I rebuilt my VM this morning at which point I had the exact same problem.
I went down all sorts of paths and the only approach that seemed to have any effect was adding
--userns=keep-id:gid=20to theruncommand as that adds thejovyanuser to a group with the same GID as thestaffgroup in macOS. Addinguid=501to remap the user has no effect (for fairly obvious reasons, I assume). This at least changed the permissions required for write access from 777 to 770/775 for folders and 666 to 664/0 so that was an improvement.However, I suddenly realised that there were two ways to configure the machine: with Apple's hypervisor or with the newer default Krunkit. I rebuilt the machine for the nth time but this time forcing it to use
applehv(export CONTAINERS_MACHINE_PROVIDER="applehv"). Suddenly bindmounts worked again with zero permissions issues.I've now tested this by initialising a second VM with the same specs but using the newer libKrun default and have confirmed that this VM does not allow me to successfully mount host directories that are writeable/accessible as if by the user running podman.
I don't believe it's anything specific to my image, but just in case here's the command that works with hypervisor and not with libKrun:
As a final step I did also try to ensure that it wasn't a missing library by following an apparent suggestion to:
That didn't fix anything so I've now brew uninstalled it.
Am I missing something? I will confess that the container <-> VM <-> host UID/GID mapping element is really at the limit of my understanding but I do feel like I chased down every viable lead for solving this with libKrun and kept having to come back to using Apple Hypervisor as the only way forward.
Suggestions gratefully received. This discussion builds on an exchange on BlueSky which was really helpful but a little constrained for exploring the issue since I couldn't give a full background or really understand the options.
Relevant Hardware/Software Information
Mac:
Podman:
Beta Was this translation helpful? Give feedback.
All reactions