The aforementioned forum thread mentions:

Upon starting the session I am presented with an error box saying "XFCE PolicyKit Agent" and "GDBus.Error:org.freedesktop.PolicyKit1.Error.Fail ed: Cannot determine user of subject"

which suggests that the XFCE policykit agent is failing to start somehow.  I'd argue that is the source of the problem here, and it should be triaged there first.

TL;DR Not sure what component to blame. This seems to be an unsupported integration issue.

In assumption that ssh -X is used to forward X protocol through the tunnel, I tend to expect systemd does not care about any forwarding and it's too early because there's no user session as ssh creates by help from an (interactive) shell to let the agent ask for user's credentials.

I did a total new install, starting with:

Fedora-Xfce-armhfp-29-20181002.n.0-sda

Then a dnf update.  Separate complaint about the poor performance of F29 Xfce over F28 Xfce.

I then do:

systemctl set-default multi-user.target
dnf install tigervnc-server
cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service

edit this to change <USER> to my id, rgm.  I 'su - rgm' (all this from the serial console) and run vncpasswd.  I really think that at this point something should create ~/.vnc/xstartup as we will see shortly.

firewall-cmd --add-port=5901/tcp --permanent
firewall-cmd --reload
systemctl daemon-reload
systemctl start vncserver@:1

And of course it fails.  I now again 'su - rgm' and edit ~/.vnc/xstartup to:

xstartup
#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
# exec /etc/X11/xinit/xinitrc
exec  /bin/sh /etc/xdg/xfce4/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
startxfce4 &

exit rgm and again try:

systemctl start vncserver@:1

Still fails.  Now I have to fix SELinux for the pid file in the user account:

cat <<EOF>systemd-tigervnc.te || exit 1
module systemd-tigervnc 1.0;

require {
	type init_t;
	type user_home_t;
	class file { open read unlink };
}

#============= init_t ==============
allow init_t user_home_t:file { open read unlink };
EOF

checkmodule -M -m -o systemd-tigervnc.mod systemd-tigervnc.te
semodule_package -o systemd-tigervnc.pp -m systemd-tigervnc.mod
semodule -X 300 -i systemd-tigervnc.pp

(see bug 1626255)

Again:

systemctl start vncserver@:1

And it starts!  I vnc to :5901 and I get the policykit error.

On a recommendation from the Fedora users list I add PAMName to service section:

[Service]
Type=forking
WorkingDirectory=/home/rgm
User=rgm
Group=rgm

PAMName=login

PIDFile=/home/rgm/.vnc/%H%i.pid

ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/bin/vncserver -autokill %i
ExecStop=/usr/bin/vncserver -kill %i

Restart=on-success
RestartSec=15

I actually power cycle so that vncserver is dead and everything is clean and check just to make sure then

systemctl start vncserver@:1

and get

Job for vncserver@:1.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status vncserver@:1.service" and "journalctl -xe" for details.

So...

# systemctl -l --no-pager status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; disabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Fri 2018-10-05 08:07:03 EDT; 1min 10s ago
  Process: 906 ExecStart=/usr/bin/vncserver -autokill :1 (code=exited, status=0/SUCCESS)
  Process: 886 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill :1 > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)

Oct 05 08:06:53 localhost systemd[1]: Starting Remote desktop service (VNC)...
Oct 05 08:07:03 localhost systemd[1]: vncserver@:1.service: New main PID 934 does not belong to service, and PID file is not owned by root. Refusing.
Oct 05 08:07:03 localhost systemd[1]: vncserver@:1.service: New main PID 934 does not belong to service, and PID file is not owned by root. Refusing.
Oct 05 08:07:03 localhost systemd[1]: vncserver@:1.service: Failed with result 'protocol'.
Oct 05 08:07:03 localhost systemd[1]: Failed to start Remote desktop service (VNC).

But I try anyway to connect to :5901 via vnc and IT IS RUNNING!  And I connect without the policy error.  But no 

/home/rgm/.vnc/localhost:1.pid

So the PAMName seems to help, some and causes other issues.

> cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service

What's the difference to the following command with a call of systemctl (or the like)? Maybe systemd does not properly recognize an activation of this vncservice?

# systemctl enable vncserver@:1.service

All in all, I fail to see any relation to Xfce in general or xfce-polkit in particular. Maybe blame another component instead, as already guessed.

Well, normally, after I have setup the vncserver@:1.service file and did the initial start, THEN I enable it so that it will start automatically on boot.

This time I have held off the enable so I can 'manually' start it to see what it is doing.

My understanding from all the systemctl examples I have read is first you deamon-reload, then start and start again (with deamon-reloads everytime you change the service file) until you have it successfully started, and THEN you enable it for all future uses.

I have seen an email that KDE DE has a similar problem, so it is not just for Xfce; Xfce is all I use.  I don't know about Gnome, but I would not be supprised if it works for Gnome as that is probably the test environment.  The default xstartup file is for Gnome; see bug 1633811.

I am only blaming what the error is reported.  What caused this error is for someone with greater skills and understanding of the many moving parts to hopefully answer.

Well, I would suggest to first start with questioning any proper packaging of tigervnc. Reassigning and I'm out of this bug because I get too much e-mails. In the hope my comments could help a little bit to encounter more details to debug.

And, unfortunately, this is not a new problem, going back at least to F27.  Others have managed a workaround:

https://forums.fedoraforum.org/showthread.php?316905-PolicyKit-failed-over-headless-VNC&p=1809280#post1809280

I reported it as a bug.

Silly question while looking into the spec file:
Shouldn't the service get automatically enabled (*) after a successful installation? Maybe something is going really odd with the unit file (**).

https://src.fedoraproject.org/rpms/tigervnc/blob/master/f/tigervnc.spec#_256
https://src.fedoraproject.org/rpms/tigervnc/blob/master/f/vncserver.service

Please try in a terminal:
# rpm -q tigervnc-server

(*) https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#_activation
(**) https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#_unit_files

Re: "I fail to see any relation to Xfce in general or xfce-polkit"

I do, xfce-polkit is crashing, per my comment #1

# rpm -q tigervnc-server
tigervnc-server-1.9.0-3.fc29.armv7hl

For me, the copy and customizing the .service file for my user account is practically automatic and perhaps a carryover from prior versions.  Plus rad the comments at the beginning of:

/lib/systemd/system/vncserver@.service

If the cp to /etc is no longer needed, perhaps fix the provided .service file?

Also I like to run 2 copies.  :1 all the time for my user account and :2 when I need it for root.  It is nice to have root with a gui when there are lots of things to straighten out.  I do this on my Samba server for fixing things on my wife's files...

And to Rex, with the PAMName entry I am able to elevate priviledges to mount a usb drive.

xfce-polkit needs a user dbus, which I do not think vncserver starts by default. 

Try adding: 

ExecStartPre=/usr/bin/dbus-launch

in the [Service] section of the vncserver unit file.

I am in a hospital bed after being hit by a car.

it could be a week before i am home to begin to see when i can start testing again.  :(

Woah, no hurry at all. Get better soon!

back at it (rt arm still in a sling, so my arm work is a little restricted :) )

I added the dbus line:

[Service]
Type=forking
WorkingDirectory=/home/rgm
User=rgm
Group=rgm

PAMName=login

UtmpIdentifier=%I
UtmpMode=user

PIDFile=/home/rgm/.vnc/%H%i.pid

ExecStartPre=/usr/bin/dbus-launch
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/bin/vncserver -autokill %i
ExecStop=/usr/bin/vncserver -kill %i

Restart=on-success
RestartSec=15


it failed to start:

# systemctl start vncserver@:1
Job for vncserver@:1.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status vncserver@:1.service" and "journalctl -xe" for details.

# systemctl -l --no-pager status vncserver@:1.service
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; disabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Thu 2018-11-22 14:05:54 EST; 56s ago
  Process: 878 ExecStart=/usr/bin/vncserver -autokill :1 (code=exited, status=0/SUCCESS)
  Process: 854 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill :1 > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
  Process: 835 ExecStartPre=/usr/bin/dbus-launch (code=exited, status=0/SUCCESS)

Nov 22 14:05:43 localhost systemd[1]: Starting Remote desktop service (VNC)...
Nov 22 14:05:54 localhost systemd[1]: vncserver@:1.service: New main PID 898 does not belong to service, and PID file is not owned by root. Refusing.
Nov 22 14:05:54 localhost systemd[1]: vncserver@:1.service: New main PID 898 does not belong to service, and PID file is not owned by root. Refusing.
Nov 22 14:05:54 localhost systemd[1]: vncserver@:1.service: Failed with result 'protocol'.
Nov 22 14:05:54 localhost systemd[1]: Failed to start Remote desktop service (VNC).

I have not updated this system since I last logged in back on Oct 4...

Odd. Try removing that line in the service file and editing your xstartup file and replace 'startxfce4' with 'dbus-launch startxfce4' ?

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.