Bans keep wiping (urgent)

[guushiyt]

Versions
ULib v2.63
ULX v3.73

Gamemode - TTT

Hello, I literally can not figure this issue out. I've tried EVERYTHING from reinstalling ulx/ulib to completely wiping data. Nearly everytime the server restarts my bans are being wiped. The weird thing is there is no errors in the console and sometimes it wipes a portion of the bans or nearly all of them.

[JamminR]

Remove ALL addons/subscriptions, put only Ulib and ULX back on, test and see what happens.
Two possibilities, the second more likely - first, bans became corrupt, ULib attempts to check its own bans file, rebuild it.
Permanent bans are not usually touched in this instance. (ULX uses the standard gmod bans file for permanent bans)
Second, sounds like an exploit - remove all recently added addons/subscriptions - if youve not added any lately, one of them has been updated to include exploit.

[guushiyt]

All add-ons I use on this server is used on the other one. This is a complete barebone vanilla ttt server. The add-ons that I use on here are simply for quality of life reasons and they're on my other TTT server which has worked perfectly fine for 4+ years.

[JamminR]

And?
Subscriptions get updated - sometimes exploited.
Things can become corrupt, and things can get exploited. If you are really unlucky, both can happen.
Check if you have a bans_backup.txt in server data\ULib. If you do, ULib sees a corruption of some sort and is attempting to recreate the file.
Server console would say this on startup (you mentioned no errors though)

Check your server/cfg/bans files - ULib tries to read all the standard gmod ban files from there. If those are being wiped, it's not by ULX (we only use standard Gmod/source commands to write those when banning)
See some troubleshooting here - https://forums.ulyssesmod.net/index.php/topic,10997.msg55171.html#msg55171

[guushiyt]

There never has been a backups file created. Also want to mention that I'm running the server on Linux. Not sure if that's an issue or not.

[guushiyt]

Anyone else have a clue?

[JamminR]

If it's not a permissions issue in linux (can user gmod runs as read and write to \data\ULib and \cfg?)
You didn't answer. Is your \cfg bans file being wiped. ULX only reads from it, source engine writes to it.

I know people hate removing hundreds of subscriptions and as many manual addons, but, really, 99.9% of time, a conflict or exploit is causing such an issue of something being wiped.
Having the exact same items on a different server may just mean it loads differently, or, exploit hasn't been used.

[MrPresident]

Try running TTT and ULX with no other mods and see if this problem persists. This is definitely a conflict somewhere and no one is going to be able to just "have an idea". Sorry.

[guushiyt]

If it's not a permissions issue in linux (can user gmod runs as read and write to \data\ULib and \cfg?)
You didn't answer. Is your \cfg bans file being wiped. ULX only reads from it, source engine writes to it.

I know people hate removing hundreds of subscriptions and as many manual addons, but, really, 99.9% of time, a conflict or exploit is causing such an issue of something being wiped.
Having the exact same items on a different server may just mean it loads differently, or, exploit hasn't been used.

It is being wiped, yes.

[JamminR]

Try running only TTT and unmodified ULib/ULX.
If it happens there, then we have more chance of assisting you.
Until then, too many variables.
You've had two experienced devs and server owners tell you - it's a conflict or an exploit.
I'm not sure how else someone can help.

[guushiyt]

So weird thing is, it seems to be only the perm ban option that is wiping.  If we ban people for hours or days it doesn't wipe. So if it's like 999 days it's fine, perm ban wipes tho.

[JamminR]

This leads me to 99.999% certainty that it is not ULX causing your issue. (where before, I was only 99.98%)
ULib only uses Source commands for permanent bans, in addition to storing reason/admin data in the ULib ban txt.
We never write to the permanent ban \cfg files directly.