Bug 1431454 - Cannot access backing file .. (as uid:4294967295, gid:4294967295): No such file or directory
Summary: Cannot access backing file .. (as uid:4294967295, gid:4294967295): No such fi...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2017-03-12 18:51 UTC by Richard W.M. Jones
Modified: 2017-03-27 16:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-27 13:36:08 UTC


Attachments (Terms of Use)
test-v2v-i-ova.sh.log (69.34 KB, text/plain)
2017-03-12 18:51 UTC, Richard W.M. Jones
no flags Details
test-v2v-i-ova.sh.log (72.03 KB, text/plain)
2017-03-13 10:33 UTC, Richard W.M. Jones
no flags Details
libvirtd.log (xz-compressed) (805.22 KB, application/x-xz)
2017-03-13 10:35 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2017-03-12 18:51:08 UTC
Created attachment 1262260 [details]
test-v2v-i-ova.sh.log

Description of problem:

Running the v2v/test-v2v-i-ova.sh gives a nonsensical error
about the backing file:

Original error from libvirt: Cannot access backing file 
'test-v2v-i-ova.d/test-ova.ova' of storage file 
'/home/rjones/d/libguestfs/tmp/v2vovl6f0542.qcow2' (as uid:4294967295, 
gid:4294967295): No such file or directory [code=38 int1=2]

$ id
uid=1000(rjones) gid=1000(rjones) groups=1000(rjones),10(wheel),135(mock) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

The uid/gid are completely wrong.

Version-Release number of selected component (if applicable):

libvirt-3.1.0-1.fc27.x86_64

How reproducible:

100%

Steps to Reproduce:
1. In the libguestfs test suite, make -C v2v check

See the attached log for a lot more details.

Comment 1 Richard W.M. Jones 2017-03-12 18:53:51 UTC
I should probably note here:

(1) It's not being run as root.

(2) The directory is readable and permissions are normal:

$ ls -al v2v/test-v2v-i-ova.d
total 4016
drwxrwxr-x.  2 rjones rjones    4096 Mar 12 18:49 .
drwxrwxr-x. 17 rjones rjones   24576 Mar 12 18:53 ..
-rw-rw-r--.  1 rjones rjones 4075520 Mar 12 18:49 test-ova.ova

Comment 2 Richard W.M. Jones 2017-03-12 18:55:25 UTC
(In reply to Richard W.M. Jones from comment #0)
> Running the v2v/test-v2v-i-ova.sh gives a nonsensical error
> about the backing file:
> 
> Original error from libvirt: Cannot access backing file 
> 'test-v2v-i-ova.d/test-ova.ova' of storage file 
> '/home/rjones/d/libguestfs/tmp/v2vovl6f0542.qcow2' (as uid:4294967295, 
> gid:4294967295): No such file or directory [code=38 int1=2]
> 
> The uid/gid are completely wrong.

And the other point here is that the file *does* exist.

This worked in earlier versions of libvirt.

Comment 3 Peter Krempa 2017-03-13 07:13:33 UTC
The attached log file is the client log file. Please attach the debug log from libvirtd.

Comment 4 Richard W.M. Jones 2017-03-13 10:33:56 UTC
Created attachment 1262383 [details]
test-v2v-i-ova.sh.log

Comment 5 Richard W.M. Jones 2017-03-13 10:35:13 UTC
Created attachment 1262384 [details]
libvirtd.log (xz-compressed)

Comment 6 Richard W.M. Jones 2017-03-24 22:39:28 UTC
I re-enabled this test as somehow this has 'fixed itself' ...  Hmmm,
I don't really believe that bugs fix themselves.

Comment 7 Peter Krempa 2017-03-27 13:36:08 UTC
So the rather weird uid/gid reported is an artifact of using the session mode, since that does not initialize any uid/gid into the qemu config. We use -1 cast to uid_t to use the current ID but the error message does not reflect this. This is not the problem though.

The problem is that you attempt to use a relative image path with JSON protocol specification. Libvirt expects that anything looking like a protocol specification (which JSON is) is an absolute path.

 string={ "file": { "driver": "raw", "offset": 10752, "size": 4063232, "file": { "driver": "file", "filename": "test-v2v-i-ova.d/test-ova.ova" } } }

I'm not sure if libvirt wants to support a configuration like this at all. I'd suggest you use a proper relative name without the JSON protocol to do relative paths, or use absolute paths.

While your configuration can work with qemu, using relative paths may fail since they are relative to the current working directory of libvirtd.

Comment 8 Richard W.M. Jones 2017-03-27 16:44:13 UTC
At least that explains why the bug fixed itself.  It's because of
this change that I made:

https://github.com/libguestfs/libguestfs/commit/91b5fb3641c91ff4e4778879d4bc866089923c28


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