After Upgrade to v12.1 can no longer write to hardened Linux rep

[tgx]

I completed an upgrade from v11 to 12.1 yesterday. There were no errors during the upgrade.
There was a warning that my hardened Linux repo was not quite hard enough and it wanted me
to use a non-root user. I created a user veeamback and ensured it had su capability. For some
reason after the update all of my jobs are now failing with the same message:

Cannot connect to targetbackup repository
Error: Permission denied POSIX: Failed to create or open file [/datastore/backups]
The directory exists and I am able to move around in the directory as user veeamback.
Veeamback cannot write in that directory unless I use su. I assume that is correct behavior.
Has anyone else encountered this? It seems like an easy fix.

Thanks.

[tgx]

I should note also that I went under Backup Infrastructure, put the extent into Maintenance mode and then
looked at the properties. If I go through each item one at a time on the properties of the Repository, all tests
are fine until you get to the Apply step at which time it pops permissions errors on the folder. So I know its a permission
error just do not know the procedure to resolve it aside from adding permissions to the veeamback user which is probably
counterproductive to the hardening process.

[karsten123]

your user has to be owner of your repository directory. please visit helpcenter. it is all very well documented

[Andreas Neufert]

In my environment after upgrade I had to update as well the Hardened Repository. For this I went to the Infrastructure Managed Server and went to the Linux System with the hardened repository. Then right-click Properties and I went through the wizard again. You have to give the one time user again (as it is not saved) and elevated to root (with credential). In the end of the wizard the software was updated and I could do a rescan of the repository (all green). For me then everything worked again.

I am not sure if this is needed in any environment, but my lab was kind of in a not ideal state as I switched a lot server and versions for testing.

[tgx]

Yes I have tried re-running the one time password setup several times. I chose
to let the installer update the agents and software and it all ran without error.
The only error I started receiving after the update was failed to connect to
repository. I have an open case at this point. It may be related to ownership of
the directory.

[Andreas Neufert]

Please check on filesystem who is the owner of the files and folders. I had the same when I used the wrong user on the Linux for the one time password.

[tgx]

You are correct Andreas. Since this repository predated the 'immutable' storage trend the owner was
not correct. It seems like there should be a check that fails during the upgrade but it does not.

[Andreas Neufert]

We do not "touch" the data when implementing a repository or run through the wizard, because a rescan can take a lot of time (hours) when there is a lot of data on them.
If you perform a rescan, we touch all the data and then it should fail. As well when a job tries to access the data or folders.
Looks like works as designed.

Anyway we could check to make the error message more clear and add a hint, that the ownership could be an issue, which would streamline the resolution.