Another Database Failed to Update - after image capture

  • Updated from SVN 7294 to 1.3.0-RC5 if that makes any difference.
    Running on CentOS7

    Have made the modification to /var/www/fog/lib/fog/fogmanagercontroller.class.php on line 23 to remove strict mode error spam.

    fogguiuser/pass are set in .fogsettings, all usernames and passwords are also set in .fogsettings, and the FTP access appears to work correctly now.

    Get the following error on the client being captured:


    In the images folder, the new image is there correctly, but shows the following ownership still

    drwxrwxrwx. 2 root root 4.0K Aug 3 15:19 Win10EngBaseInstall5

    Restoring images works fine with no errors however, so if seems to be failing to change ownership.

  • Senior Developer

    Can you try applying the fix as described in the patch and see if uploads work for you now? I’ve added this to what will be RC-8 at least.

  • Senior Developer

    @jbender So that will be available relatively soon in the “RC” cycles (unless we decide to go full fledged lol).

  • @Tom-Elliott That looks to have removed the issue.

  • Senior Developer

    Can you try applying the fix as described in the patch and see if uploads work for you now? I’ve added this to what will be RC-8 at least.

  • Senior Developer

    @jbender I suppose the chmod is not really necessary then. It was there as a failsafe I believe.

    I’ll remove it for RC-8, which should fix the problem for you a bit more readily.

  • @Tom-Elliott No the chmod does not run. The files have a 777 mod, and do not change until I manually run a chmod myself afterwards. I’ve also been manually changing the files ownership afterwards, since they are not owned by the fog user.

    Since the chmod fails to complete, it signals an error in the capture script, never finishes a database update (which I am unsure what update that is), and causes the captured machine to run an auto-reboot after 1 minute.

    However, the task completes on the fog server and the image captured this way seems to be ok.

    Again this was not the behavior previously, and the system had not been changed otherwise until updating to the 1.3.0-RC5-6 trunk from svn 7929 trunk. Honestly never paid attention to ownership when they were captured previously, but the previous images were all correctly owned by fog user from before.

  • Senior Developer

    From the sounds of things, the chmod is working either way, because at the point the command runs the files are in 777 mod, the chmod simply changes it from 777 to 755.

  • Would it be possible to include a CHOWN command ahead of the CHMOD attempt?

    From what I can tell that is what is missing. The images are captured owned by Root, the process that does the CHMOD in ftp is logged in as the “fog user” (I think). So if the CHMOD succeeds, the “fog user” would be cut off from having permissions to the final file.

    I’ve been trying to find the relevant parts in the php files, and only know enough to be dangerous. Where are the commands that the fog capture script runs from? If I can find that might be able to add it myself as a test.

  • @Tom-Elliott

    No it is empty.

  • Senior Developer

    @jbender Is there anything the /var/log/xferlog file?

  • @Tom-Elliott

    Unfortunately, same result still.

  • Senior Developer

    @jbender Just on a limb, would you mind removing the /var/www/fog and /var/www/html/fog directories and rerun the installer?

  • Now updated to 1.3.0-RC6

    Still have the same error after image captured, database update fails.

    jbender Storage Group: default
    Storage Node: DefaultMember 2016-08-04
    09:01:45 2016-08-04
    09:17:20 15 minutes 35 seconds Win10-EngBase-Install-6 Capture Complete

    – On the FOG Interface side, Image capture is complete

    My /images mount had been set to 777 permissions, have set back to 755, with fog:root as owner as before.
    drwxr-xr-x. 21 fog root 4.0K Aug 4 09:17 images
    /dev/sdb1 on /images type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

    – Nothing special about /images that I know of.

    Directory listing of images:

    drwxr-xr-x. 21 fog root 4.0K Aug 4 09:17 .
    dr-xr-xr-x. 21 root root 4.0K Aug 3 17:07 …
    drwxr-xr-x. 2 fog root 22 Aug 4 09:17 dev
    -rwxr-xr-x. 1 fog root 0 Apr 18 16:10 .mntcheck
    drwxr-xr-x. 2 fog root 29 Apr 18 16:10 postdownloadscripts
    drwxr-xr-x. 2 fog root 4.0K May 11 12:43 Win10BaseInstall4
    drwxr-xr-x. 2 fog root 4.0K May 19 15:09 Win10BaseInstall5
    drwxr-xr-x. 2 fog root 6 May 9 12:48 Win10BaseInstallStartCustom1
    drwxr-xr-x. 2 fog root 6 May 9 13:22 Win10BaseInstallSysprep1
    drwxr-xr-x. 2 fog root 4.0K Aug 3 15:19 Win10EngBaseInstall5
    drwxrwxrwx. 2 root root 4.0K Aug 4 09:17 Win10EngBaseInstall6

    – /images/dev folder gets emptied correctly after capture, the new image gets moved into /images/imagename

    I’ve noticed that the image while being captured in /images/dev is owned by root:root, and when it gets moved back into /images, it is still owned by root:root. All other images where captured under SVN version 72xx series and have ownership set to fog:root. Should there be a step that changes ownership to fog:root before the chmod is done?

    Forgot to add:

    – From httpd error log:

    [Thu Aug 04 09:17:20.183936 2016] [:error] [pid 17703] [client] PHP Warning: ftp_chmod(): SITE CHMOD command failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 31

    — VSFTP.conf

    – Not really sure what else to check.

  • @Wayne-Workman
    [root@fogmachine ~]# sestatus
    SELinux status: enabled
    SELinuxfs mount: /sys/fs/selinux
    SELinux root directory: /etc/selinux
    Loaded policy name: targeted
    Current mode: permissive
    Mode from config file: permissive
    Policy MLS status: enabled
    Policy deny_unknown status: allowed
    Max kernel policy version: 28
    [root@fogmachine ~]# getenforce
    [root@fogmachine ~]#

  • What is the output of sestatus and getenforce ?

  • Senior Developer


    I’m running rc5 at work and have uploaded many images without this issue. That said, the chmod simply tries to change the file permissions to 0755. From the sounds of this, it almost seems the /images folder is masked?

Log in to reply