[solved] Windows standard users can't access DCs sysvol and user GPOs are not applying (error 1058)

So basically coming to the end of my rope, just started grepping for any errors anywhere in the logs and I could see a lot of messages:

Jun 20 10:18:35 dcm1 univention-mount-homedir: Failed to mount home directory: '/home/<username>'

Basically the same as this thread: Login via SSH fails for a single user: Failed to mount home directory

If I remove the home share attribute from the user account under POSIX (Linux/UNIX) section then sysvol/netlogon browsing works as it should!! I guess the failing home mount, failed the user login through samba to pam and broke the sysvol browsing!

So now I have a work-around that I can blank out the home share attribute and get my user GPOs working again.

Looks like NFS mounts are failing from the file server.

Fileserver systemctl status:

● nfs-server.service - NFS server and services
   Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-06-20 16:58:03 AEST; 7min ago
  Process: 3968 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE)
      CPU: 2ms

Jun 20 16:58:03 filestore systemd[1]: Starting NFS server and services...
Jun 20 16:58:03 filestore exportfs[3968]: exportfs: Failed to stat /var/lib/univention-client-boot: No such file or directory
Jun 20 16:58:03 filestore systemd[1]: nfs-server.service: Control process exited, code=exited status=1
Jun 20 16:58:03 filestore systemd[1]: Failed to start NFS server and services.
Jun 20 16:58:03 filestore systemd[1]: nfs-server.service: Unit entered failed state.
Jun 20 16:58:03 filestore systemd[1]: nfs-server.service: Failed with result 'exit-code'.
Warning: nfs-server.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Is it that Failed to stat /var/lib/univention-client-boot: No such file or directory thats the issue?

Used to run UCC clients from this file server (not now, app was uninstalled) and it’s come through a few upgrades. Some sort of hang over from earlier like this other example for NFS?

edit:
Looking in UCR there seem to be leftover values from UCC.

root@filestore:/var/lib# ucr search ucc
appcenter/prudence/docker/ucc: yes

logrotate/syslog-ucc/.*: <empty>
 Configuration options for logging UCC-client rsyslog-messages (for possible options see description of ucrv logrotate/*)

logrotate/syslog-ucc/rotate/count: 7
 Configuration options for logging UCC-client rsyslog-messages (for possible options see description of ucrv logrotate/*)

logrotate/syslog-ucc/rotate: daily
 Configuration options for logging UCC-client rsyslog-messages (for possible options see description of ucrv logrotate/*)

security/packetfilter/package/ucc-remotelog/tcp/514/all: ACCEPT
 Variables following the scheme 'security/packetfilter/PACKAGE/*' are packet filter rules shipped by UCS packages (see 'security/packetfilter/use_packages'). They should not be modified.

security/packetfilter/package/ucc-remotelog/udp/514/all: ACCEPT
 Variables following the scheme 'security/packetfilter/PACKAGE/*' are packet filter rules shipped by UCS packages (see 'security/packetfilter/use_packages'). They should not be modified.

ucc/image/defaultid/desktop: ucc30desktop

ucc/image/defaultid/thinclient: ucc30thin

ucc/image/download/url: http://ucc-images.software-univention.de/download/ucc-images/

ucc/image/path: /var/lib/univention-client-boot/

ucc/pxe/append: syslog=y syslogserver=<server IP>

ucc/pxe/bootsplash: true

ucc/pxe/loglevel: 0

ucc/pxe/nfsroot: <server IP>

ucc/pxe/timezone: <server timezone>

ucc/pxe/traditionalinterfacenames: true
 If set to 'false', predictable network interface names will be deactivated. As this collides with UCC default settings, the value is 'true' by default. If the variable is unset, it is evaluated as 'false'.

ucc/pxe/vga: 788

Can these all be safely deleted?