-
- Enthusiast
- Posts: 51
- Liked: 62 times
- Joined: Feb 11, 2019 6:17 pm
- Contact:
After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
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.
-
- Enthusiast
- Posts: 51
- Liked: 62 times
- Joined: Feb 11, 2019 6:17 pm
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
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.
-
- Service Provider
- Posts: 508
- Liked: 126 times
- Joined: Apr 03, 2019 6:53 am
- Full Name: Karsten Meja
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
your user has to be owner of your repository directory. please visit helpcenter. it is all very well documented
-
- VP, Product Management
- Posts: 7145
- Liked: 1532 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
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.
-
- Enthusiast
- Posts: 51
- Liked: 62 times
- Joined: Feb 11, 2019 6:17 pm
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
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.
-
- VP, Product Management
- Posts: 7145
- Liked: 1532 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
-
- Enthusiast
- Posts: 51
- Liked: 62 times
- Joined: Feb 11, 2019 6:17 pm
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
not correct. It seems like there should be a check that fails during the upgrade but it does not.
-
- VP, Product Management
- Posts: 7145
- Liked: 1532 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: After Upgrade to v12.1 can no longer write to hardened Linux rep
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.
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.
Who is online
Users browsing this forum: No registered users and 59 guests