Observed Behavior

When trying to use any claims on the server it says we need someone(UUID)'s permission and makes it so no one on my server can use their claims.

Expected Behavior

When trying to use any claims on the server it should say we need (Username)'s permission, also it should actually work.

Reproduction steps

1. Have a 1.19 server with GriefPrevention 16.18.
2. Try to use a claim.
   I don't know how else to describe this.

Stack trace or error log

Not Applicable.

Server version

This server is running Paper version git-Paper-81 (MC: 1.19) (Implementing API version 1.19-R0.1-SNAPSHOT) (Git: 86f87ba)

You are running the latest version

GriefPrevention version

GriefPrevention version 16.18

Configuration

# Default values are perfect for most servers.  If you want to customize and have a question, look for the answer here first: http://dev.bukkit.org/bukkit-plugins/grief-prevention/pages/setup-and-configuration/

GriefPrevention:
  SeaLevelOverrides:
    FNAFSB: -1
    FNAFSB_nether: -1
    FNAFSB_the_end: -1
    coolio_the_end: -1
    coolio: -1
    world1_the_end: -1
    world1_nether: -1
    Event: -1
    world1: -1
    coolio_nether: -1
  Claims:
    Mode:
      coolio_the_end: Disabled
      world1_nether: Disabled
      coolio: Survival
      FNAFSB_nether: Disabled
      FNAFSB_the_end: Disabled
      world1_the_end: Disabled
      FNAFSB: Disabled
      coolio_nether: Disabled
      Event: Disabled
      world1: Survival
    PreventGlobalMonsterEggs: true
    PreventTheft: true
    ProtectCreatures: true
    PreventButtonsSwitches: true
    LockWoodenDoors: true
    LockTrapDoors: true
    LockFenceGates: true
    EnderPearlsRequireAccessTrust: true
    RaidTriggersRequireBuildTrust: true
    ProtectHorses: true
    ProtectDonkeys: true
    ProtectLlamas: true
    InitialBlocks: 100
    Claim Blocks Accrued Per Hour:
      Default: 200
    Max Accrued Claim Blocks:
      Default: 32000
    Accrued Idle Threshold: 0
    AccruedIdlePercent: 0
    AbandonReturnRatio: 1.0
    AutomaticNewPlayerClaimsRadius: 0
    AutomaticNewPlayerClaimsRadiusMinimum: 0
    ExtendIntoGroundDistance: 5
    MinimumWidth: 5
    MinimumArea: 10
    MaximumDepth: -2147483648
    InvestigationTool: STICK
    ModificationTool: GOLDEN_SHOVEL
    Expiration:
      ChestClaimDays: 9999999
      UnusedClaimDays: 9999999
      AllClaims:
        DaysInactive: 9999999
        ExceptWhenOwnerHasTotalClaimBlocks: 10000
        ExceptWhenOwnerHasBonusClaimBlocks: 5000
      AutomaticNatureRestoration:
        SurvivalWorlds: false
    AllowTrappedInAdminClaims: false
    MaximumNumberOfClaimsPerPlayer: 0
    CreationRequiresWorldGuardBuildPermission: true
    VillagerTradingRequiresPermission: true
    CommandsRequiringAccessTrust: /sethome
    DeliverManuals: true
    ManualDeliveryDelaySeconds: 30
    RavagersBreakBlocks: true
    FireSpreadsInClaims: false
    FireDamagesInClaims: false
    LecternReadingRequiresAccessTrust: true
  Spam:
    Enabled: false
    LoginCooldownSeconds: 60
    LoginLogoutNotificationsPerMinute: 5
    ChatSlashCommands: /me;/global;/local
    WhisperSlashCommands: /tell;/pm;/r;/whisper;/msg
    WarningMessage: Please reduce your noise level.  Spammers will be banned.
    BanOffenders: true
    BanMessage: Banned for spam.
    AllowedIpAddresses: 1.2.3.4; 5.6.7.8
    DeathMessageCooldownSeconds: 120
    Logout Message Delay In Seconds: 0
  PvP:
    RulesEnabledInWorld:
      FNAFSB: false
      FNAFSB_nether: true
      FNAFSB_the_end: true
      coolio_the_end: true
      coolio: false
      world1_the_end: true
      world1_nether: true
      Event: false
      world1: true
      coolio_nether: true
    ProtectFreshSpawns: true
    PunishLogout: true
    CombatTimeoutSeconds: 15
    AllowCombatItemDrop: false
    BlockedSlashCommands: /home;/vanish;/spawn;/tpa
    ProtectPlayersInLandClaims:
      PlayerOwnedClaims: true
      AdministrativeClaims: true
      AdministrativeSubdivisions: true
    AllowLavaDumpingNearOtherPlayers:
      PvPWorlds: true
      NonPvPWorlds: false
    AllowFlintAndSteelNearOtherPlayers:
      PvPWorlds: true
      NonPvPWorlds: false
    ProtectPetsOutsideLandClaims: false
  Economy:
    ClaimBlocksMaxBonus: 0
    ClaimBlocksPurchaseCost: 0.0
    ClaimBlocksSellValue: 0.0
  ProtectItemsDroppedOnDeath:
    PvPWorlds: false
    NonPvPWorlds: true
  BlockLandClaimExplosions: true
  BlockSurfaceCreeperExplosions: true
  BlockSurfaceOtherExplosions: true
  LimitSkyTrees: true
  LimitTreeGrowth: false
  PistonMovement: EVERYWHERE
  PistonExplosionSound: true
  FireSpreads: false
  FireDestroys: false
  AdminsGetWhispers: true
  AdminsGetSignNotifications: true
  VisualizationAntiCheatCompatMode: false
  SmartBan: true
  Mute New Players Using Banned Words: true
  MaxPlayersPerIpAddress: 3
  SilenceBans: true
  Siege:
    Worlds: []
    BreakableBlocks:
    - GRASS_BLOCK
    - DIRT
    - COBBLESTONE
    - OAK_PLANKS
    - SPRUCE_PLANKS
    - BIRCH_PLANKS
    - JUNGLE_PLANKS
    - ACACIA_PLANKS
    - DARK_OAK_PLANKS
    - SAND
    - GRAVEL
    - GLASS
    - GRASS
    - FERN
    - DEAD_BUSH
    - WHITE_WOOL
    - ORANGE_WOOL
    - MAGENTA_WOOL
    - LIGHT_BLUE_WOOL
    - YELLOW_WOOL
    - LIME_WOOL
    - PINK_WOOL
    - GRAY_WOOL
    - LIGHT_GRAY_WOOL
    - CYAN_WOOL
    - PURPLE_WOOL
    - BLUE_WOOL
    - BROWN_WOOL
    - GREEN_WOOL
    - RED_WOOL
    - BLACK_WOOL
    - SNOW
    - GLASS_PANE
    DoorsOpenDelayInSeconds: 300
    CooldownEndInMinutes: 60
  EndermenMoveBlocks: false
  SilverfishBreakBlocks: false
  CreaturesTrampleCrops: false
  RabbitsEatCrops: true
  HardModeZombiesBreakDoors: false
  Database:
    URL: ''
    UserName: ''
    Password: ''
  UseBanCommand: false
  BanCommandPattern: ban %name% %reason%
  Advanced:
    fixNegativeClaimblockAmounts: true
    ClaimExpirationCheckRate: 60
    OfflinePlayer_cache_days: 90
  Abridged Logs:
    Days To Keep: 7
    Included Entry Types:
      Social Activity: true
      Suspicious Activity: true
      Administrative Activity: false
      Debug: false
      Muted Chat Messages: false

Plugin list

Plugins (18): ajAntiXray, BKCommonLib, ChatEx*, CoreProtect, Essentials, EssentialsSpawn, floodgate, Geyser-Spigot, GriefPrevention, InventoryRollbackPlus, LuckPerms, My_Worlds, SoaromaSAC, Vault, ViaVersion, voicechat, WorldEdit, WorldGuard

Running without GriefPrevention

• I attempted running the server without GriefPrevention installed.
• The problem does not occur when GriefPrevention is removed from the server.

Running with only GriefPrevention

• I attempted running only GriefPrevention on the server.
• The issue still occurs when GriefPrevention is the only plugin running.

Running on a fresh, clean server installation

• I attempted testing for the issue on a new server.
• The issue still occurs on a new server.

Using unmodified client

• I attempted testing for the issue with the vanilla client.
• The issue still occurs when using the vanilla client.

We appreciate you taking the time to fill out a bug report!

• I searched for similar issues before submitting this bug report.

You're delusional.

I know this may come as a shock to you, but name calling won't actually help reproduce your issue! Maybe you could provide a copy of a nonfunctional setup, ideally including logs of one of the users joining and coordinates where they were denied access to a claim. Logs of them joining on a functional copy would also be good so we can verify that their UUID is actually the same across both. If you have a good backup that you used to restore your server, maybe you have a bad backup you can use to help track down the problem. Perfectly willing to reopen this if you can provide any sort of proof that it's GP at fault and not a general problem with your server that happened to affect GP, but if you keep tossing insults I'm equally willing to add you to my block list instead.

GP only displays "someone(UUID)" when the server reports them as having been offline for over a certain threshold. If you're seeing this for players who are active, it's usually caused by a bad modification of their player data (which results in the Bukkit NBT tag containing their last join being deleted from their save data). That said, since you claim (but again, no proof/reproduction case) that users were denied access to their own claim, it is far more likely that either you changed some configuration or the server itself was in error, causing UUIDs to be different for the "same" players.

I cannot load the bad backup due to how my server host is setup. I'd have to download the entire server then load the backup, then download that backup, then reupload the current server in chunks of 2 gigabytes at a time.

Ofcourse I checked the UUIDs to see if they matched up, and they did. I had not updated anything in my configs for at least a week prior to this even happening. It happened after a scheduled server restart, perhaps GP decided to corrupt something? I don't know, I assumed it was just because the plugin hadn't been updated for 1.19. But then it should've broken when I added it 2 months ago.

I decided to just revert to a backup and that fixed the issue. I'd hope that this big of an issue wouldn't be idiotically overlooked with a simple "It doesn't happen for me."

I think some of your plugins may cause GP to save UUIDs differently, remember, I'm not the author of the plugin, I just quickly tested it with a clean, fresh server. If there is still an issue, you can reset the UUID saving mechanism.

I tested the bug, and for me, there is no issue. If you don't mess up the UUID, everything works perfectly.

Try only running grief prevention and see if the issue is still present.

Inflammatory language is really not gonna get you anywhere when seeking support for free open source software.

GP does not do its own UUID/name fetching. If you're seeing issues with incorrect UUIDs that still look like UUIDs (i.e. not corrupted GP data) odds are on that you have made some other change to your server that has in turn affected GP. For example, if you were to swap your server from online to offline mode and delete your usercache, you would see similar effects on GP.

This may be bad configuration, a bad plugin (i.e. you're running floodgate, maybe you installed a corrupted build that you have since rolled back as part of your general rollback) or it may be the server itself miscommunicating with Mojang, but it's not GP at fault.

Okay, hm. That's unfortunate, because it means the easiest theory is shot. That host's backup system sounds incredibly inconvenient and I completely understand not wanting to restore the bad state to get to the bottom of things. The problem with it being something on GP's end is that if the claim data was corrupted it wouldn't load (if there was a save failure the UUIDs should be un-parsable garbage), which would delete problematic claims. For the UUIDs to all exist but be different would require some kind of outside interference as far as I'm aware.

I can reopen this if you like, but frankly because it's not reproducible it most likely means that this issue would just become a stale mystery until eventually the saving process gets rewritten in v18 or whenever it is on the roadmap for and we end up saying "yeah this thing is probably fixed but who knows, get in touch if it happens again."

The fact that specifically the UUIDs changed is incredibly weird, there should be no way that the data would be corrupted like that and still be readable into actual otherwise-functional claims. No errors in the log prior to the corruption I take it?

I doubt you'll get a satisfactory answer if it isn't reproducible, unfortunately.

To this day that still hasn't happened again so I still do not know.

It happened after about a month or two out of nowhere. Same plugins, no
changes. Some claims stopped working, others didn't.

I didn't send this by the way. Haven't even had internet in the past 5 days..

I didn't send this by the way. Haven't even had internet in the past 5 days..

Oh, that's kinda scary unless it was a message that didn't send correctly back when this was active before. May want to double check your email to make sure it's secure just in case.

I guess I'll re-close then, but if you do run into it again, we can absolutely open this back up.

I doubt someone hacked my account to resolve an issue I no longer have with my Minecraft server. I assume it was just hella late.