Issue: Finalising Image Capture

[Nuit]

Hi,

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 ?

Cheers, Nuit

[Nuit]

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.

[Tom Elliott]

What happens if you run commands:

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

[Nuit]

Hi,

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.

[Quazz]

@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 sestatus

[Nuit]

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:

[Quazz]

@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.

Try setenforce 0 and see if that helps. May have to restart the ftp service.

[Nuit]

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.
Cheers, Nuit

[george1421]

@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.

[Nuit]

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.

Cheers Nuit