Docker load fails with "permission denied"

[Butch]

I am trying to load a docker image (tar archive created by docker save) using the following command:

docker load --image image.sav

However, I get the extremely useful and informative error message:

open image.sav: permission denied

As you can see, I’m running as root and the file has permissions 777, so there really shouldn’t be an issue:

root@caracalla:~/sap# docker load --input image.sav
open image.sav: permission denied
root@caracalla:~/sap# id
uid=0(root) gid=0(root) groups=0(root),115(pkcs11)
root@caracalla:~/sap# ll sap_dynamic_edge_processing_docker_image.sav 
-rwxrwxrwx 1 admin admin 2030671872 Jun 26 18:23 image.sav*

Does anyone have any suggestions? I need to be able to load this image in order to do a vendor certification, but if I can’t get our software onto the device, it’s really hard to certify that it works.

Thanks!

[gary-wzl]

Hi Butch
Could you please try the following command then do it again?

 $ snap connect docker:home :home

The reason here is that you place your image in your $HOME. And home plug is not auto-connected. So you need to connect it manually before you go.

Also please make sure the image file is owned by root instead of admin, otherwise you’ll get the apparmor denial.

$ sudo chown root.root image.sav

These rules will be also applied to docker subcommand like build, import and docker.compose.
So in general, to make sure above subcommands working in snappy world, you need to

1. Make sure docker has proper access permission on files like Dockerfile, docker-compose.yml or images. E.g. you could consider putting these files to locations such as $HOME, $SNAP_USER_DATA, $SNAP_DATA… etc. Also make sure home plug is connected if you place files in $HOME.
2. Make sure these files owned by root. As of now, it’s not supported yet to use docker without sudo in snappy world due to lack of feature about users&groups management

There’s a similar situation someone ran into.

Please let me know if it works for you.
Thanks.

BR
Gary

[Butch]

@gary-wzl Your suggestions, plus a reboot, seem to have worked.

Thanks!

[gary-wzl]

Actually, you don’t need to a reboot. But it’s good to hear it works for you.
Regarding why we need to make sure these files owned by root, I copy&paste @jdstrand’s previous comment here. Please take a look.

@jdstrand

This is often caused because root is trying to write to a directory or file that it doesn’t have write access to. Eg, root tries to write to a dir that is 0755 and owned by foo:bar. Unconfined root runs with CAP_DAC_OVERRIDE which allows it to write to it. Assuming the problem is what I described, you need to take a look at what the application is doing and either adjust the directory/file permissions or adjust the code in some manner to not trigger this. Also, depending on how the program is written, dac_override may be non-fatal. See man 7 capabilities for details.