When I'm on the console, I type in: pex user smyname I get back the following:
'UUID/smyname' is a member of:
TheWorld (not ranked)
UserPlayer (not ranked)
smyname's permissions:
smyname's options:
name= "smyname"
So far, it looks good (UUID is provided, omitting for privacy).
But if I use pex group TheWorld or UserPlayer here is where the trouble starts. The list returns the permission nodes granted or denied, but I'm not seeing them all.
1-6 are shown
257-263 are shown
514-594 are shown
I have no idea why 7-256 and 264-513 are missing from the list. Out of all the plugins, all I get are the AutoRank, Essentials (some) and WorldEdit (some) returning and that's only 3 out of 30+ plugins. Anyone else seen this? Even with my full access group (Admin), I get some autorank, some essentials, some massivecore and some worldedit.

I've tried reorganizing the permission nodes with denies first, denies second, denies at TheWorld (top) and denies at the UserPlayer group. It varies slightly so I believe I'm just hitting a bug in the list code that is suppressing all the results. Attached an edited copy of the permissions.yml.
permissions.yml.txt
PermissionsEx 1.23.4
Spigot Server 1.11.2 (last build)
Windows 10 Pro x64 O/S
Java 1.8.0_131 x64

Thanks! -Steve

Unfortunately PermissionsEx is currently unmaintained and no further updates are planned. Because of this, all pull requests are being closed. If you are looking for an actively maintained permissions plugin, take a look at LuckPerms. It is compatible with major server platforms and can import data from PEX.

I'm not fully understanding what you're trying to do with your (3?) groups— TheWorld, OwnerAdmin, and UserPlayer.

The first time a user enters your server, they belong to the group named "TheWorld" and can do virtually everything. Anyone in "UserPlayer" can't do anything at all. And "OwnerAdmin" looks like it can do everything too.

As far as I can see, the only major error is the location of the schema-version: 1 line— which should be above the users: section line —and the inclusion of an info: section, which contains options: section settings.

A much less important issue is that your permissions file is over 1750 lines long because you have 3 groups with the same permission nodes (and sometimes, the same permission node multiple times in one group).

Any group with an inheritance from "TheWorld" doesn't need to list any of the permission nodes "TheWorld" gets in their own group. (i.e., Line 311 and 327, for "OwnerAdmin" is the same permission node as line 10 in "TheWorld". Since "OwnerAdmin" inherits everything "TheWorld" has, lines 311 and 327 can be deleted.)

You can take a look at this example to see proper inheritance and formatting for the permissions.yml file.

In this example, a member of the "Admin" group gets permission.node.one because it inherits the permissions of the "Mod" group, "Mod" inherits all the permissions of "Member", and "Member" inherits all the permissions of "Guest". If all of these groups had listed permission.node.one (and other nodes that other groups before them got), the file would become excessively long and more difficult to read and troubleshoot if problems occurred.

Thanks Stormbow, I really appreciate the feedback on this. My goal was to list all the permission nodes allowed to TheWorld (default), and in the UserPlayer have all the negated permissions or the other way around to make sure players can't do what is stated, but can do what we allowed. So as a user joins, they are granted the permissions needed for the plugins and then the group they are associated with is used to make sure to negate permissions they shouldn't have. I ran it through the parser with P3 Groups and it passes the syntax check but not when I try pex group/user commands. Most of the permission nodes are not shown.

I'm curious if there is anything that can be done to help spot (or preferably) remove duplicate permission nodes during a /pex reload, restart of the server, comment them out or flag them in the console as a potential duplicate. Perhaps someone created a utility that can flag all the duplicates or can validate the PermissionsEx permissions.yml?

Given the volume of plugins I have, there is no escaping having an extra long file so I wouldn't expect that to be an issue. I'm only using 32 plugins, but I've seen some server owners have double that. :-)

I ran it through the parser with P3 Groups and it passes the syntax check but not when I try pex group/user commands.

I think this is a common result from most YAML checkers. They're checking for basic YAML formatting/indentation/punctuation/no-tab-key-usage and not for PEX-required or other-plugin-required information sections/names, etc. So, in this case, the file "parses clean", but the info: section may not be read by plugins such as EssentialsChat/EssentialsXChat— which is what most servers use to display prefixes/suffixes in-game —as (I believe) it looks for those settings in an options: section. (Honestly though, I've never used or seen used an info: section; it's definitely not "standard operating procedure" when manually editing the permissions.yml file and isn't a section created when the permissions.yml file is generated by using PEX Commands only.)

As far as why the entirety of the permissions a group/users gets and inherits is not displayed...well...we'd have to have @zml2008 answer that one. As far back as (at least) Minecraft 1.6.4, I haven't needed/cared what the in-game display showed because I always knew what was in my permissions.yml file, and in the past 4-5 years that I've been the "official" PEX guru (actually part of the team), I think you're among less than 5 people who expressed an interest in that display, so I never learned more about it.

Oh, and we can check groups for one specific node— pex user <user> check <permission> [world] — or use debug mode to check into why a group/user can't do a specific thing.

When it comes to duplicate permission nodes, I'm not sure what you mean. I would simply not put lines 311 and 327— the duplicate node in your file —into a group. LOL And if I opened the permissions file in notepad and saw duplicates, I'd manage them through inheritances as much as possible to shorten my file.

I ran 55 plugins on my server when I was at the height of my server-running days, so I know what you mean about the potential for extremely long files. The longest permission file I've had to troubleshoot was over a prison server that had over 18,000 lines (including the users section; the permissions along were just under 9,000 lines) and the longest server startup log I ever saw was almost 3,900 lines long. (I saved them both on my computer, for multiple reasons.) In comparison, by using wildcards and inheritances, my server's file was 874 lines, not including the users section.

Thanks - makes sense. I'll go through the file and remove all the dups. I've removed the ones mentioned and made the changes suggested. I've changed info: to options: and the list on the console is only slightly different. Here is the output for it attached.
pex-console.txt
And the full permission.yml is here.
permissions.yml.txt

The console issue with the iterating of the list of permission nodes is something I saw with the Residence plugin owned by Zrips. In one release, using res listall as a command, it would list some, skip over some and list some more instead of listing all of them. He was able to fix the logic, so that's what I thought was going on here. I can use the command you provided to check permission and it does say I have it, but just not reflected on the console. :-)

I've had users complain they get into a world and can't click on doors or build when the permissions clearly show they should be able to, which is how I got to this state. I'm trying to reconcile what the user says they can/can't do with what the console shows and what the file (permissions.yml) has listed. Seeing the difference prompted me to come here and ask why. :-)

AWESOME!! This helps me understand it much more and do appreciate your reviewing the files to tell me what was wrong with it. The list I got is probably where the problem comes in since I used GroupManager and found it isn't being supported/fixed for any reason, so I moved to PEX for exactly this reason (support). :-) There are many iterations of Essentials* named plugins and it is quite possible I used them incorrectly by combining them into what I have now. Clearly, not the right way to do this.

I'll review and change all your highlighted points (especially the last one with giving myself the PEX access and not having them in the yml file, I do like that idea a lot).

SaneEconomy plugin allows for me to create/use a Server account that's used for paying players when the are in a certain Job (woodcutter, fisherman, etc.). I couldn't find an option in Essentials that allowed the same and if it does, I'm more than willing to drop something unnecessary. Simple is always better! :-) Thanks again for the extra help and your time, it is greatly appreciated.

For what it's worth, I can offer up this little nugget of info too:

Spigot servers— which is virtually everyone, these days —should be using EssentialsX and EssentialsXChat (+ Vault).

I always let plugins create money out of thing air, so I never really looked into Essentials creating a server bank account to pay people from. That's an interesting idea though.

Let me know how everything works out for you. If everything's OK, you can close the ticket below. If you have more questions, you can always ask here (even if the ticket is closed).

(I'd leave it open though, to see if @zml2008 can answer about the permissions list printing to the console.)

I've had users complain they get into a world and can't click on doors or build when the permissions clearly show they should be able to, which is how I got to this state. I'm trying to reconcile what the user says they can/can't do with what the console shows and what the file (permissions.yml) has listed. Seeing the difference prompted me to come here and ask why. :-)

Ahhhh! The root of the problem. Have you used Debug Mode before? Many servers find that plugins like WorldGuard (an extremely commonly used plugin) is preventing access to stuff because of region definitions and missing WorldGuard permissions, and Debug Mode has discovered those hidden permission nodes were missing from the groups/users.

Some other stuff I noticed in your permissions file:

• Line 7 should be indented 2 more spaces, to be under its options: section.

• Line 286: default: 'false' does nothing. You only need to add default: 'true' to one group on the server. (default: 'false' would also go under options:, if it did do anything.)

• When you have a permission node like jobs.* (line 689), PEX will see that line and know that the group gets every permission node related to that plugin, and not pay attention to any jobs.anything nodes that come after it. (This is why we negate nodes, above wildcards.) Line 689 thus makes lines 690-742 a waste of space.

• The "SaneEconomy" plugin may be redundant. If it does anything that Essentials doesn't do, of course keep it; otherwise you might want to lighten your server load by removing it and allowing Essentials to handle your economy.

• Doublecheck your permission nodes to verify they're actual nodes for the plugins you're using. This is another major cause of users not being able to do things they expected they should be able to do. For example, Line 76— essentials.kit.use —is not actually an Essentials node as far as I'm aware. On a similar note, Line 67, 519 (and maybe more) should be plural— essentials.extinguish.others and essentials.kit.others. If you create any kits for the server, those nodes would also be plural — "kits", essentials.kits.wood. Line 59— essentials.clearinventory.use —is another non-existent node.

♦ Lines 851 - 886: I typically recommend not giving PermissionsEx access to a group because if anyone hacked their way into the group or otherwise gained access to PEX commands, they could literally delete all of the groups on the server, give themselves permissions you weren't expecting, and sometimes even delete plugin-created backups of the server. It's also best to give yourself direct access to PEX Commands with the command pex user Stormbow add permissions.* (using your Mc name, of course) so if you ever need to move yourself to another group to test permissions and the server setup, you don't lose access to PEX.

Ok, we'll see what @zml says about why this is this way.

I can tell you that no changes will be made in PEX 1.x, but it may work differently or be added to PEX 2.x (which is currently still in development).

Okay, just got done doing my testing as a player (TheWorld) default group and not OP'd and everything is working. I confirmed also that while I cannot see it in the chat window, the chat history logfile is being written and DOES have all the permissions. So there is a temporary workaround to verify what I was trying to do. Attached it as a reference and it was in the %appdata%.minecraft\logs folder (had to dig for that one). :-) So waiting for 2.x is fine by me and makes sense too especially since that's the release in development.
2017-06-06-2.log.gz

Thanks - just got thru removing all the duplicates and setting it up so TheWorld is the default for all users with all the allowed permissions and the OwnerAdmin adds the other permissions that these users can use and reduced the size to just over 1000 lines. :-) I did a pex reload and still see an abbreviated list of all the permissions. I restarted the server in case the reload didn't really reload and no difference in behavior.

So it does appear to be a bug "only when you use the console to list the permissions" (pex group TheWorld or pex group OwnerAdmin). In game using the same commands, I "think" it is listing all of them, though it doesn't support pagination (next page / previous page) so I can actually verify they are all there. This is exactly the same bug I had for Residence where the in-game commands showed the results, but on the console it didn't.

Bug 1 - console should list all permission nodes for a given group name (pex group xxxx) with no pagination (doesn't make sense on a console).
Bug 2 - in-game should list all permission nodes for a given group name (/pex group xxxx) with pagination similar to below. This would actually be required because of the chat history is restricted to xx number of rows and all you'll end up seeing is the tail end of the permission nodes.

Here is the console image after reloading the changes to permissions.yml and the permissions.yml itself in case that can pinpoint where the problem is.

Here is the tail end of the perms for OwnerAdmin

pex-console.txt
permissions-updated.yml.txt