Application export issue

Is the user account doing the export an admin account?  If not, do they have at least viewership permissions for the group identified in that error message?

There were several objects with the same privileges, all those were loading into export, except that one particular object.

Can you confirm whether or not the same issue happens when doing the export from an Admin-level account?

No error when I try to export using admin-level account.

Ok, I'm fairly certain this confirms that the basic user trying to do the export doesn't have sufficient permissions to the group identified in the error message.

Is it advisable to perform export and import using admin-level account.

That totally depends on the best practices and dev hierarchy specified by your dev team leaders and product owners.

In my case, I'm lucky enough to be in charge of an application and environment cluster where I have full sway over the dev cycle, and run an admin-level account as my usual account.  I personally utilize the built-in environment-direct-deployment tool nearly 100% of the time for deployments from our Dev environment to higher environments, which sidesteps many of these issues for lower-level accounts (though the account doing the deployment may still require at least viewership-level permissions over the objects being deployed, i'm not super sure without trying it myself first). 

At the same time, there are projects out there with larger and/or greater numbers of dev teams in place and only the project leadership would have Admin-level accounts, and the other developers would have Basic-level accounts, with elevated permissions (by virtue of having been added to the "Designers" and "process model editors" groups, etc).  These developers would ostensibly have access only to application packages belonging to applications they actually work on (and would be in groups giving them permissions into specific ones only, for instance).  There isn't only one "right" way.

That totally depends on the best practices and dev hierarchy specified by your dev team leaders and product owners.

In my case, I'm lucky enough to be in charge of an application and environment cluster where I have full sway over the dev cycle, and run an admin-level account as my usual account.  I personally utilize the built-in environment-direct-deployment tool nearly 100% of the time for deployments from our Dev environment to higher environments, which sidesteps many of these issues for lower-level accounts (though the account doing the deployment may still require at least viewership-level permissions over the objects being deployed, i'm not super sure without trying it myself first). 

At the same time, there are projects out there with larger and/or greater numbers of dev teams in place and only the project leadership would have Admin-level accounts, and the other developers would have Basic-level accounts, with elevated permissions (by virtue of having been added to the "Designers" and "process model editors" groups, etc).  These developers would ostensibly have access only to application packages belonging to applications they actually work on (and would be in groups giving them permissions into specific ones only, for instance).  There isn't only one "right" way.