Cannot Capture Image - Failed to open stream

[hummela]

One of my coworkers has approached me saying he cannot capture an image from one of our new Dell OptiPlex 7090 computers. From what I can tell, it uploads the image correctly to the /images/dev folder but fails when trying to move it to the /images folder. He told me that uploading an image from a different computer (a Dell Latitude 3520) works as intended. I have tried logging into the storage node that is being uploaded to with ftp and created a file/moved it successfully, but the OptiPlex will not play nice. Something curious that I noticed, it seems that the capture process is uploading as root instead of fogproject. The folder in /images/dev will be owned by root, and after the transfer to the /images folder will remain as root (in the case of the Latitude), the OptiPlex will put files in the /images/dev folder as root but will not complete the move.

Other info:
Running FOG server dev-branch 1.5.9.147 on a VM (10.1.0.27) with locations enabled, tftpboot to this server
Running FOG storage node dev-branch 1.5.9.147 on a physical server (10.1.0.115), uploading correctly to this server

Screenshot of the error that FOG spits out when it fails:

[george1421]

@hummela This is an interesting one.

So when FOG uploads an image to the server it places it in /images/dev/<mac_address> directory. The Updating database error message is a bit misleading. Because there are a few steps between sending the image to the fog server and updating the database.

After the files is uploaded (this part is known by you because you tested it) the FOS Engine connects to the FOG server using FTP using the fogproject user ID and it issues a mv command to move the directory /images/dev/<mac_address> to /images/Dell7090Staff directory.

This step is failing.

Either the fogproject user can’t issue the move command or the move command is failing because of a permission problem. As you alluded to. The permissions on /images/dev diectory should be owned by root or fogproject and group fogproject

The issue here is that the FOS Engine (that runs on the target computer) runs as root in FOS. That is why the files are coming in as root, that’s root on the FOS engine but not root of the FOG Host server. Confusing but the way it works.

Its strange why this system is failing for only this 7090 where it works with a different model. Are you running the latest version of the FOS Linux kernel (5.15.x) found in the WebUI->FOG Configuration->Kernel update.

[hummela]

@george1421

I can confirm I am using the FOS kernel 5.15.34, as I tried updating that to see if that had been the issue.

both /images and /images/dev are owned by fogproject with group root, as are the directories inside.

[george1421]

@hummela Ok then lets try the mechanics of this.

I assume in /images/dev directory there is a botched upload. The directory will have the name of the mac address of this host.

First lets confirm this directory exists /images/dev/7486e211bc42

on a windows (or other computer) ftp to the fog server. Login as fogproject with the password found in the hidden file /opt/fog/.fogsettings

from the ftp command prompt key in mv /images/dev/7486e211bc42 /images/Dell7090Staff That is the mechanics of what is going on behind the screen. What the error message is saying that it can’t access /images/dev/7486e211bc42 to move the file or /images/Dell7090Staff is blocked (maybe because of permissions) so it can’t moved the file

[hummela]

@george1421

Confirmed that there is a folder in /images/dev named 7486e211be88, which has the files in it.

FTP moving was interesting. An image had previously been uploaded using this folder name in /images (something the other tech failed to tell me). So this was actually the second capture attempt for the same image. My FTP rename was unsuccessful the first time until I realized there was already a directory with the same name in the /images folder. I deleted that directory and the rename was successful. It seems that it has to do more with overwriting an existing image with an updated one.

[Sebastian Roth]

@hummela Seeing that you are using the very latest dev-branch version I am a bit worried this is something caused by the changes made to add PHP 8 support lately.

I will look into this soon and report back.

[hummela]

Just as a bit of an update -

I manually deleted the /images/Dell7090Staff directory and had him try capturing the image again. This time, the image captured successfully. It definitely seems like an issue overwriting an existing image with a new one.

[george1421]

@hummela OK so from a truth table standpoint we think we see the error (good debugging by the way)

So what we don’t know is with the now successful upload can he reupload without making any changes. In my mind we don’t know if the permissions on the previously uploaded directory were bad where someone might have changed the permissions for some reason (not shaming here, we simply don’t know), there was something else with a lock on that directory, or the updates to the fog programming to support php8 as Sebastian mentioned, caused this.

[hummela]

@george1421

I had him try to capture to the same image again and it failed in the same way - Failed to open stream.

[george1421]

@hummela ok then on the fog server would you run these two commands.

On the destination images
ls -la /images
ls -la /images/Dell7090Staff

and then on the captured directories
ls -la /images/dev
ls -la /images/dev/7486e211bc42

You can/should also purge that /images/dev/7486e211bc42 because its a botched upload. The files in Dell7090Staff are untouched so you should be able to deploy those without issue.

Good debugging steps here. We should get to the bottom of this issue with your help.

[hummela]

@george1421 said in Cannot Capture Image - Failed to open stream:

@hummela ok then on the fog server would you run these two commands.

On the destination images
ls -la /images
ls -la /images/Dell7090Staff

and then on the captured directories
ls -la /images/dev
ls -la /images/dev/7486e211bc42

Ignore the fact that the mac address changed - he tried capturing again from a different host (bad troubleshooting there, I know). The capture still failed in the same way with this host.

[Sebastian Roth]

@hummela I just reverted one of the changes I made when adding the PHP 8 support. Would you mind updating to 1.5.9.148 and trying again?

[hummela]

@sebastian-roth

Updated and he has confirmed it worked. Captured from the same host twice just to make sure.

Thank you so much for looking into this!