uid 65534 after kernel update

verdon

Well-Known Member
Nov 1, 2003
945
16
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
Hi,

Recently my DC did a kernel update for me to '2.4.21-47.ELsmp #1 SMP Tue Aug 1 08:47:53 EDT 2006 i686 i686 i386 GNU/Linux'. The previous kernel was quite old and additionally I was having trouble with iptables. After the new kernel, I began to have permission issues all over the place. At first I thought it might have been non cpanel versions of some services that were causing the problem and re-installing a number of things like exim and mailscanner and doing an upcp --force solved a lot of issues.

Since, I have been discovering lots of other permissions problems that I think I have narrowed down to this... it looks as if when the kernel update was done that the user 65534 was created. Doing some searching here and on google has explained that this is normal with some updates to the kernel for CentOS and others. What also appears to have happened is that any file (or at least lots I've looked at) that were owned by nobody before the update are now owned by 65534, and this seems to be the root of a lot of problems with scripts that upload and manipulate files/images. New files put on the server by said scripts are owned by nobody (as they should be) but there are issues if nobody is trying to put something in a dir owned by 65534 and so on.

It looks like I may have a lot of work ahead of me to correct this. I'm wondering if anybody else has experienced this? I'm also wondering what files should be owned by 65534?

Any tips or thoughts?

Thanks,
v

WHM 10.8.0 cPanel 10.8.2-R119
CentOS 3.8 i686 - WHM X v3.1.0
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
uid 65534 is usually used for the nfsnobody account. If you're not running nfs, ten no files should be owned by that account and if they are I would guess something has gone awry, especially if they're in /home. It's possible that there's a bug somewhere mistaking the nfsnobody account for nobody, but you would hope not.

To fix:

find /home -user 65534 -exec chown -v nobody:nobody {} \;

You could run that on other partitions/directory trees if you need to.
 

verdon

Well-Known Member
Nov 1, 2003
945
16
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
Thanks Chirpy,

As always, a succinct and extremely helpful answer :)

As to using nsf, seeing how I didn't even know what it was until I started googling today, I don't think so. I do think my DC made some errors compiling a custom kernel for me (custom on their reccomendation). As some of the other errors/ommisions were not including iptables modules that had become corrupt and led to me requesting a new kernel in the first place, I'm in process of waiting for it to be done again.

In the meantime, I'm going to chown any files owned by 65534 to nobody starting at /home, and then I'll see if any files are owned by 65534 anywhere else.

Thanks again,