Simple and fast question:

kevin@pc:/usr/lib/jvm$ ls -l
total 8
lrwxrwxrwx 1 root root   25 Feb 20 17:31 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root   21 Apr 23 20:34 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
drwxr-xr-x 7 root root 4096 Jun 12 15:25 java-11-openjdk-amd64
drwxr-xr-x 8  668  668 4096 Jun 12 12:12 jdk-11.0.3

Who/what is this 668 user?? I'm the only one using this machine.

cat /etc/passwd | grep 668

Doesn't show anything with the number 668

Additional info: I installed jdk-11.0.3_linux-x64_bin.deb via GUI

  • 1
    I'm tempted to say somebody ran chown 668 instead of chmod 668 but that doesn't really add up. – Panki Jun 13 at 12:24
  • @JeffSchaller I just double clicked on jdk-11.0.3_linux-x64_bin.deb and installed it via GUI – Kevin Jun 13 at 12:31

I believe what you are seeing is files / directories belonging to a non-existent user. Linux mostly uses numbers to represent users rather than names usernames are effectively a lookup to a number. If the UID (number) doesn't exist in /etc/passwd (or other nsswitch mechanisms) this won't prevent files from belonging to that numeric userid.

Examples of causes include:

  • At some stage there may have been a user with uid 668, but that user has since been deleted.
  • Extracting an archive which uses UID's not names (eg tar file).
  • Simply setting the ownership with chown
  • Plugging a hard drive from another computer
  • 1
    Or the files have been extracted from some archive, preserving the UID stored in the archive. – Kusalananda Jun 13 at 12:26
  • 1
    @Kusalananda Now I think of it there's a massive number of reasons this can happen. No point in listing them all, but might as well give some examples. – Philip Couling Jun 13 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.