Issue: Finalising Image Capture
running Fog 1.4.2 on Debian CentOS-7.1511 (the whole thing is a VM running on ESXi 5.5)
and have one of these quite common problems with the image capture not getting finished:
Searched the forum and went trough the according Wiki: Troubleshoot FTP - FOG Project
- reset password for the “fog”-user everywhere,
- reset folder permissions and ownership
- checked vsftpd.conf and .fogsettings
- verified web interface settings
- verified network settings
- verified that plenty of space is available
- just for testing annihilated any firewall functionality on the Debian machine
Still does not work.
So what’s the thing at:
The images get captured and are found in “/images/dev” (under their MAC address) but no named folder for the image is created in “/images” and the files are not moved if a new image is captured or if an existing image should be overwritten, the overwrite does not happen.
So the task in FOG never finishes and the client is ending with the error pictured above.
Ran some tests on FTP availability (going there from a Windows machine).
Loging in with the standard FOG user, works fine, puts me to the “/home/fog” folder, where I can create subfolders, put, get, del files etc.
But when I move over to the “/images” folder no creating folders, files or whatsoever anymore:
Giving the results, I’d assume there is some permission problem somewhere, so the question is what did I miss ?
Stupid side fact: The whole thing worked til December like a charm. We were deploying images during the last few month just fine. Only found out about the error when trying to update the images recently. And no one here remembers having changed anything about the server (as usual).
Any help would be appreciated.
Ok, config for SELinux has been changed, did a reboot for testing, looking good so far.
Even if I still do not know, how the SELinux got enabled at all, it looks like the issue is solved.
Thank you very much to all of you guys who helped with the issue.
@nuit SELINUX needs to be disabled for FOG to function correctly. Please check /etc/selinux/config and ensure that its set to permissive. The setenforce command will only work until your FOG server is rebooted then the value of selinux will return if you don’t update the selinux config file.
Yay…that kinda did it.
The setenforce 0 and restarting the FTP did the trick.
So question is, what went wrong on the SELinux.
I am actually not aware, that I ever fiddled with it on the Debian machine to start with.
Is there any possibilty to keep this permissive mode for good, so I do not to redo it manually every time I reboot the VM ?
Or would there be any prime reason to actually fix the config for vsftpd and get it back up running again ?
Thanks a lot so far for the fix.
@nuit It is probable that SELinux is the culprit here. I believe it is disabled by default on Debian (correct me if I’m wrong).
Maybe the SELinux configuration for vsftpd isn’t set correctly.
setenforce 0and see if that helps. May have to restart the ftp service.
Ok here is the vsftpd.conf (looks the same as mentioned in the Wiki):
and the SELinux status:
FTP Service has been restarted several times by now.
But it looks like the status has even gone worse now.
I guess since the resyncing of the fog service account password. I can no longer do anything via FTP since then.
I can still log in using the “fog” user. But that’s about it. Can change directories but not even list anything anymore:
@nuit As a test, can you see if you can download any files from that folder?
Can you post your vsftpd conf here?
Not sure if you have tried this already, but just in case, what about if you restart your ftp service?
edit: Also, just in case someone enabled Selinux check with
Nuit last edited by Nuit
that was one of the first things I did when recognising this was some sort of permission problem.
“/images” ownership and all subfolders is set to fog:root
and full permissions on everything are set:
As you can see in the screenshot, the whole thing worked til December.
As mentioned before the problem seems not really to be located on folder/file level.
If I do login to the console using the “fog” user I can create/move files and folders between “/image” and any subfolders without problems.
But if I do login via FTP using the “fog” user I no longer can (getting Error 550 when trying to create a Folder and Error 553 when trying to create a file (using put command).
If I stay in the “fog” users home folder the FTP commands do work.
So I get the impression, that something with “/images” folder and it’s setting with the FTP service or the permissions of the “fog” user regarding FTP is broken.
What happens if you run commands:
chown -R fog:root /images chmod -R 777 /images
One little add: this “permission problem” seems to be somewhat connected with the FTP function.
When loggin onto the CentOS console with the “fog” user, the user can actually copy and move files within the “/images” and “/dev” folders (the file permissions are somewhat reduced) but the copy/move works.
thanks for the reply.
Yes, I did the resync too. But that did not change anything.
Regarding this, when running the reinstall of Fog for finishing the resync, there is a request to “Update the Database Scheme” via the Web Console before continuing.
Is there anything else needed doing this appart from validating the info in the Web Console?
Is there any actual function for “updating the database scheme” in the Web-Console ?
I’m sure you have already been through this tutorial. https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password The issue IS you either have the linux
foguser account out of sync or something happened so that the linux
foguser can not create files in /images.
FOG uploads images to /images/dev/<mac_address> then after the upload moves them to /images/<image_name> using ftp. If the linux user
fogdoesn’t have rights to make this move either on the source directory or destination directory then you will have an issue.