Image/Snapin Replication Failed: Group Ownership

[markbam]

Recently some of my images and snapins have been failing to replicate due to group ownership errors. I’m certain my install got messed up from migrating it across various servers/VMs.

When a snapin is uploaded via the webgui, it’s assigned “fogproject:fogproject”. This will fail to replicate.
My solution: run “chown fogproject:www-data uploadedfile.exe” and it will successfully replicate.

Is there somewhere in the configs that I can change the group back to www-data for new uploads?

Thanks

[Sebastian Roth]

@markbam said:

I’m not exactly sure which machine the chmod command is being run. Is it FogServer sending the command over the network or the StorageNode issuing the command locally?

The master node issues lftp command to sync the files over. So from what we see in the log I would think that it’s a FTP command issued by the master node but run on the storage node. But it’s kind of strange you can fix this by chown on the master node.

Node side shows some as rwxr-xr-x but the rest are rwxrwxrwx.

What if you make them all rwxrwxrwx on the storage node?

The only way I’ve been able to get it work is to change the ownership group from fogproject to www-data on the server.

As I said, this is kind of strange and I do not understand it yet. Possibly I have a wrong understanding of this issue.

So my particular issue is figuring out why Fog’s FTP once uploaded snapins as fogproject:www-data but now uploads as fogproject:fogproject.

I might be wrong but I would suspect that it never uploaded as fogproject:www-data. @Tom-Elliott what do you think?

Or figuring out why the chmod wants the permissions associated with www-data instead of fogproject.

While access rights are a combination of ownership (chown) and permissions (chmod) those are not really associated with each any further. But maybe I got you wrong on this one.

[markbam]

That log was from the Snapin Replicator log from the Fog Log viewer.
I’m not exactly sure which machine the chmod command is being run. Is it FogServer sending the command over the network or the StorageNode issuing the command locally?

Server side shows all snapins as rwxrwxrwx.
Node side shows some as rwxr-xr-x but the rest are rwxrwxrwx.

Correct, the chmod fails after the transfer and the file is removed from the storage node.
The only way I’ve been able to get it work is to change the ownership group from fogproject to www-data on the server.

So my particular issue is figuring out why Fog’s FTP once uploaded snapins as fogproject:www-data but now uploads as fogproject:fogproject. Or figuring out why the chmod wants the permissions associated with www-data instead of fogproject.

[Sebastian Roth]

@markbam Sorry, forgot to ask you on which server you see this? Please check access rights on the master node and the storage node. If I get the log message right it tries to chmod on the storage node side and fails.

[markbam]

The snapin log errors:

[11-04-19 7:52:01 am] | Started sync for Snapin ExampleZippedSnapin - Resource id #859274
chmod: Access failed: 550 SITE CHMOD command failed. (./ExampleZippedSnapin.zip)
[11-04-19 7:59:59 am] | Sync finished - Resource id #859274

It then deletes the file from the node and starts trying to sync again.

As I look again, I do see that the uploads on the server do have the correct permissions of rwxrwxrwx. But when they are replicated to the node they show rwxr-xr-x.

[Sebastian Roth]

@markbam said in Image/Snapin Replication Failed: Group Ownership:

In an working setup, what should the user:group be? fogproject:www-data or fogproject:fogproject?

Yeah, should be fogproject:fogproject.

If I understand correctly, the uploaded snapin’s user:group is determined by the account the server’s FTP is run under.

Exactly.

Recently some of my images and snapins have been failing to replicate…

Can you be more precise on how you noticed it doesn’t work? Did you see error message in the logs? Can you post those here?

[markbam]

@Sebastian-Roth

Yes, the r/w permissions look the same (777) for all new and already uploaded snapins. Only difference is the group.

In an working setup, what should the user:group be? fogproject:www-data or fogproject:fogproject?

If I understand correctly, the uploaded snapin’s user:group is determined by the account the server’s FTP is run under. I’ll take a closer look at the group permissions that fogproject runs under and if anything looks off on my set up.

[Sebastian Roth]

@markbam The upload happens using FTP (user fogproject) and it’s technically not possible to chown to a differen user ID unless you are root and this is not the case in the environment the FOG services are running. So currently the “hacky” solution to this is the FTP client does a chmod 777 to the uploaded files. This way the replication should work.

I just tested this on my server and it works well. Can you please have a look if the snapin files have rwxrwxrwx rights after the initial upload?