Check the permissions of the directory. To delete a file inside it, it should be writable by you
chmod ugo+w .
and not immutable or append-only:
chattr -i -a .
Check with ls -la and lsattr -a.
The file is an H2 file lock, from a lift-based (web) application. H2 uses an interesting file locking protocol, the file will be re-created pretty much immediately if that database is in use.
(The filename matches the default persistence database name for that framework.)
You need to stop whatever app server is running that database to get rid of that file if you want it gone. (But do you really?)
Your strace output clearly shows that the unlink is successful.
unlinkat(AT_FDCWD, "lift_proto.db.lock.db", 0) = 0
An inode number can be re-used. Filesystems could use whatever allocation strategy they want, but nothing prevents them from reallocating the same inode number.
On an idle ext3 filesystem:
$ touch a
$ stat -c %i a
593358
$ rm a
$ touch a
$ stat -c %i a
593358
$ touch a b
$ stat -c %i a b
593358
593362
$ rm a b
$ touch b a
$ stat -c %i a b
593362
593358
Best Answer
Simple answer: You can't, root can do everything.
You can set the "i" attribute with chattr (at least if you are on ext{2,3,4}) which makes a file unchangeable but root can just unset the attribute and delete the file anyways.
More complex (and ugly hackish workaround): Put the directory you want unchangeable for root on remote server and mount it via NFS or SMB. If the server does not offer write permissions that locks out the local root account. Of course the local root account could just copy the files over locally, unmount the remote stuff, put the copy in place and change that.
You cannot lock out root from deleting your files. If you cannot trust your root to keep files intact, you are having a social problem, not a technical one.