owner/group 797/796 (after rsyncing to a new hosting)
 

I used to have three websites on a shared hosting plan and I've rsynced them to a new hosting plan (self-managed, ovh, Centos7). When I look at the owner/group of these files they are 797 and 796, it looks something like this in Filezilla:

http://prntscr.com/c1wvzd

When I look at some other websites (they were transferred from a different hosting plan, I think this is the reason), the owner/group are set to root/root (which seems to be good and needed state of this). I've never created any additional groups or users on this hosting plan, so any of these 797 or 796 did not exist previously there.

Is this something that is not good and need to be change and can it cause some kind of problems with how the websites work? I was trying to find some info about it on the Net but it looks like there is nothing there on that.

So what this is, why 797 and 796, should I change it and so on? Any info about it basically would be good, as I am not sure what this is. The files were rsynced in the archive mode from a managed shared hosting plan.

Thanks.

It's the UID/GID from the previous system.
You used rsync options to preserve them.

Just change them to what you want.

It's never a good idea to have files owned by a UID that has no user name attached. Someone could create a user on your system with that UID and then the files would belong to him. You should definitely chown them, but not necessarily to root.

I seem to remember that public web pages are usually owned by a special unprivileged user.

It used to be my username, lets say "johnsmith" on the previous hosting (a text string, something like this). It has now became 797 and 796, so how would this work? Is this some kind of default for Linux or Centos? Unknown and not existing username and group -> assign to 797 and 796? Like I said, did not see anything about it on the Internet. Searching for "owner 797 group 796 linux" in google.com returns an index of a Linux book and the 797 and 796 are the pages of the book, but no info about what this could be here.

I dont have another user on the system, so I guess I will change it to root/root (unless this is not what I should do, but from what I imagine this is an acceptable thing). From /etc/httpd/conf/httpd.conf:

User apache
Group apache

So this is the user and group which Apache uses and accesses the files and folders of the websites through the >>>Other<<< Permissions (user-group-other). So is root/root ok, or would I create a "user_one" and assign it it that? I dont see a reason though, as I run everything under root. This may not be THE BEST config, but it is for slow websites, nothing very popular or exposed there... I will set up key based auth on a custom ssh port and disable password login, but I will leave the root login, as this is how I work now (I know that I should disable root login, add a user then su to the root, but I dont do it this way here). So root/root, I guess and it should be good...

descendant_command told you exactly what was going on here. Rsync does not change the owner and group on the files by default (there is a parameter to change that behavior) but it passes the data intact. The data is stored as numbers. If you use ls with the proper options, it will list out your files locally showing the numeric user and group numbers instead of names. You transferred the files with those ownerships, and they arrived with those ownerships, but on the receiving system there are no user or group names tied to those numbers so it cannot interpret them for display so it just displays the number.

Either change the ownership after transfer, before transfer, transfer using the option that remaps the ownership, add the group and user on the remote system WITH those UID and GID numbers, or live with it. Your choice. Just so you know, it is due to your activity and expected behavior: there is no bug implicated in any part of this.

Given all of this, how do you want to address these so that everything works and looks the way you want? If you try something, come back and leave a comment so we know what worked best for you.