Error returned: Type: 2 (already checked permissions/credentials)

[JoshuaIan]

Hi all.

Sorry, new here. Please forgive me if anything is out of protocol.

I’m running into what appears to be a fairly common issue. Seemingly out of nowhere (I’m unable to determine what could have changed between yesterday when it was working and today when I receive this error), attempted image uploads are failing at the point of updating the database after the pxe boot happens and the image is captured.

Error message :

Error returned: Type: 2 File: /var/www/html/fog/lib/fog/fogftp.class.php Line: 708, Message: ftp_put(): Could not create file., Host: x.x.x.x, Username: fog

I wanted to do my due diligence before asking for help, so I found the sections in the wiki regarding testing the tftp server (successful), and more to the point, the sections on troubleshooting the permissions and credentials.

I’ve verified the permissions and ownership of the /images folder using the following :

sudo chmod -R 777 /images
sudo chown -R fog:root /images

ls -laR /images appears to be correct to me as far as I can tell. Every item has drwxrwxrwx, and appears to be owned by the local fog user.

Additionally, I’ve attempted to verify credentials at all listed possible trouble spots, including :

Storage Management > Storage Node > Management Username & Management Password
Web Interface > Fog Configuration > Fog Settings > TFTP Server > Fog_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD

I’ve used sudo passwd fog to re-enter the local fog user’s password in Centos.

Lastly, I’ve ensured that the username and password of the fog user in /opt/fog/.fogsettings.

Is there anything I’m missing? Most posts I can find are resolved after looking into those settings. My current version is 1.4.4.

Please let me know if you require any screenshots or logs, I’d be happy to provide any information that assists with getting this issue resolved.

Thank you very much to anybody who took the time to read this, and especially to anybody who may be able to assist me with this issue.

Regards,
Joshua

[JoshuaIan]

This issue is resolved. Oddly enough, it appears to be related to the image names as entered. The person capturing the images was using a date (no special characters, just numbers) in the naming convention of the image. Once we attempted to capture an image without that date in the image name, the images captured successfully.

Odd, but, I’ll take it. Thanks to all for the responses.

[JoshuaIan]

So I decided to do a full rebuild, in the hopes that doing so would resolve this issue and allow me to just migrate my images over. Brand new server, shut the old one off entirely, and I’m STILL receiving this error message. Doublechecked all permissions and credentials on the new server, same deal.

How could this error message be showing up on a brand new rebuild? Both servers are using their own /images directory to store images, both have had chmod -R 777 /images && chown -R fog:root /images set.

What am I doing wrong here?

[Wayne Workman]

@joshuaian Did you install 1.4.4 on the new box? What OS are you using? Did you disable SELinux per the CentOS 7 guide? Did you configure firewalld (also in the centOS 7 guide)?

[JoshuaIan]

@wayne-workman Thank you for the response!

I’ve used the following guide to get this up and running. Before this occurred, the box had been up and running without issue for about a year or so.

http://blog.ibuddy.info/index.php/2015/06/fog-v-1-3-on-centos-7-full-install-guide/

SELinux was configured, and firewalld disabled. This guide pulled from the SVN repository, so the version it installed does appear to be 1.4.4. I had tried running the 1.5.2 installer from git, it did appear to update the web UI, but didn’t appear to resolve the updating database issue.

However, the fact that I did a fresh install and I’m still receiving the Type 2 error indicates that I’m doing something wrong (even if my original build, also using that same guide, worked well for a year). I just wish I could figure out what that is so I can get this up and running and move on with my life.

I very, very much appreciate any insight, and again, I’d be happy to pull any logs or other resources that may be requested.

Regards,
Joshua

[Wayne Workman]

@joshuaian Can you try again with our official guide?

[Quazz]

Perhaps a silly question, but is there sufficient room left on your partitions? (df -h)

[JoshuaIan]

This issue is resolved. Oddly enough, it appears to be related to the image names as entered. The person capturing the images was using a date (no special characters, just numbers) in the naming convention of the image. Once we attempted to capture an image without that date in the image name, the images captured successfully.

Odd, but, I’ll take it. Thanks to all for the responses.

[Tom Elliott]

@joshuaian What exactly was the date that it was passing. It wouldn’t matter if it was: 2018-05-13 but if the file was 2018/05/03 then it may have issues as the / represent directory separators in linux.