Veeam v11 and Synology Linux repository

[b.vanderhorst]

Since the upgrade to v11, I've getting these errors while update the (Synology) Linux Repository:
- Installing Veeam Data Mover service Error: mkdir: cannot create directory '/opt': Permission denied | mkdir: cannot create directory '/opt': Permission denied
I can make this dir myself or give elevated root but then:
- Installing Veeam Data Mover service Error: Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory | Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory

Searching on the web on releated error it seems that Veeam needs Libacl and it can not be extracted from the tar file. Found also some people that says it's related to the TAR version or something not updated on the Synology NAS.
Backups work as previous versions but the new immutable option requires the Data Mover install.

Also got this error:
Installing Veeam Data Mover service Error: tar: VeeamSecurityHelper: Cannot open: File exists
tar: libNtfsLib.so: Cannot open: File exists
tar: libacl.so.1: Cannot open: File exists
tar: libattr.so.1: Cannot open: File exists
tar: libblkid.so.1: Cannot open: File exists
tar: libfuse.so: Cannot open: File exists
tar: libuuid.so.1: Cannot open: File exists
tar: scripts/veeamtransport.service: Cannot open: File exists
tar: scripts/veeamtransport: Cannot open: File exists
tar: scripts: Cannot utime: Operation n
tar: VeeamSecurityHelper: Cannot open: File exists
tar: libNtfsLib.so: Cannot open: File exists
tar: libacl.so.1: Cannot open: File exists
tar: libattr.so.1: Cannot open: File exists
tar: libblkid.so.1: Cannot open: File exists
tar: libfuse.so: Cannot open: File exists
tar: libuuid.so.1: Cannot open: File exists
tar: scripts/veeamtransport.service: Cannot open: File exists
tar: scripts/veeamtransport: Cannot open: File exists
tar: scripts: Cannot utime: Operation not permitted
tar: vddk/lib64: Cannot utime:

Don't know what to do.

[Gostev]

Yes, v11 will be the transition period where we will support both the legacy approach (run-time Data Mover) and the new approach (persistent Data Mover). This was done specifically to give all interested 3rd party storage vendors a whole year to adapt and support the persistent Data Mover approach. We will remove support for run-time Data Mover completely in v12.

You should contact Synology and see if this is something they want to support. They can work with our Alliances to put the integration in place - this should require minor changes on their end, because our engine works out of the box with default minimal installs of all major Linux distributions.

[b.vanderhorst]

Gostev, Thanks for the quick reply.

I will check with Synology. I think it's just few minor changes that will do the trick.

I'll update this post as soon as i got some news about this.

[Robvil]

So Synology repository is still working - just not being able to install the Veeam Data Mover persistent, right?

[Gostev]

That is correct. No persistent Data Mover, and thus no access to the immutable backups feature.

Although I do not consider NAS devices to be a good candidate for the hardened repository anyway, because there are way too many attack vectors with their management interface (constant source of CVEs) and all the other software packages they are usually running.

For best protection, you want a physical server with minimal Linux install, no SSH Server and IPMI/DRAC/iLO disabled, which leaves only local, "physical" console available. This way, even if a hacker gets the root password somehow, it's going to be unusable remotely. Moreover, with adequate physical security of the local console access, this approach will even protect your backups from malicious insiders.

[b.vanderhorst]

I've contacted Synology Support, this is a part of the conversation:
Thank you for contacting us.
We created this technical support ticket for your inquiry on Synology website:

Code: Select all

Inquiry ticket: #489712

Original Content:

Category	Others
Company Name	
Job Title	
Message	Third party Veeam: (Part1)
Since the upgrade to v11, I've getting these errors while update the (Synology) Linux Repository:
- Installing Veeam Data Mover service Error: mkdir: cannot create directory '/opt': Permission denied | mkdir: cannot create directory '/opt': Permission denied
I can make this dir myself or give elevated root but then:
- Installing Veeam Data Mover service Error: Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory | Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory
URL	https://www.synology.com/en-global/form/inquiry/feature


Our Technical Support Team will follow up with this ticket. Feel free to reply to this ticket if you think there is something we should know.

Sincerely,
Synology Technical Support

Jacques Anthony MINYEM
2021-03-03 18:58:48
Dear customer,


Thank you for contacting us.

Can you please precise me if you're trying to install a third package on the NAS ? 

Can you please also provide me some screenshots that can illustrate your incident ?

Thank you.


Regards,

MINYEM JA.

Technical Support

Synology

Support is available from Monday to Friday 9.00 to 18.00.
____________________________________________________________

Need information for your configurations?
Knowledge Base & Tutorials | Download Center | Blog | Community

Need suggestions to choose your system?
NAS Selector | RAID Calculator | NVR Selector
____________________________________________________________
Email powered by Synology MailPlus

Bart
2021-03-04 21:49:20
Hi Jacques,



We are using Veeam Backup & Replication and some of the Synology Nasses are used as an Linux Backup repository. This has some advantages over SMB. We use the Synology Package Pearl for this task.



In Veeam B&R v11, the have made a new future called immutable backups. this option can help protect against crypto malware by making backups un writeable  for a period of time.



w8LxLC7xzXxWQAAAABJRU5ErkJggg==



This option needs the "Data mover" service installed on the NAS, that fails with this error:

DwItqu6aEaSlAAAAAElFTkSuQmCC 

Installing Veeam Data Mover service Error: Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory
Failed to invoke command /opt/veeam/transport/veeamtransport --install 6162: /opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory



Veeam Support says there needs to be some changes on the Linux distribution side.



They are eager to help you guys and assist in making that possible.



I have three customers already asking if we can enable this future for them.



Can Synology assist and contact Veeam on what to do?



Kind Regards,



Bart van der Horst

Senior Project Consultant.

Beerepoot Automatisering

The Netherlands

Jacques Anthony MINYEM
2021-03-05 15:39:11
Dear customer,

 

I thank you for your feedback.

I'll discuss about it internally and I'll come back to you once I'll have a feedback from our developers.

However, being a third installation, we shouldn't be able to assist for this kind of issue.

I'll let you know after exposed your issue you our internal team.

Thank you for your understanding.

 

Regards,

MINYEM JA.

Technical Support

Synology

Support is available from Monday to Friday 9.00 to 18.00.
____________________________________________________________

Need information for your configurations?
Knowledge Base & Tutorials | Download Center | Blog | Community

Need suggestions to choose your system?
NAS Selector | RAID Calculator | NVR Selector
____________________________________________________________
Email powered by Synology MailPlus

Jacques Anthony MINYEM
2021-03-08 12:29:42
Dear customer,

 

I will also suggest you ask Veeam Support Team if there is a way to install manually the Veeam Data Mover service in a Linux environment.

https://www.veeam.com/nl/support.html
Can you also in an SSH connection know the architecture bit of your NAS using "uname -a"  ? 

If you don't know how to connect to your NAS through SSH, you can check the following procedure : 

https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet 
Please then send me the screenshot of it and also the answer from Veeam Support Team.

I thank you for your understanding.

 

Regards,

MINYEM JA.

Technical Support

Synology

Support is available from Monday to Friday 9.00 to 18.00.
____________________________________________________________

Need information for your configurations?
Knowledge Base & Tutorials | Download Center | Blog | Community

Need suggestions to choose your system?
NAS Selector | RAID Calculator | NVR Selector
____________________________________________________________
Email powered by Synology MailPlus

Basically they are asking if the Data mover service can be installed manually, is this possible?

[Gostev]

Well, I'm quite positive that everything we do automatically can also be done manually but I'm also sure there's no documented, tested and supported process for this at the moment.

I can also see how complex manual process will result in many mistakes, invalid configurations and support cases, so I'm not sure if this is something we'd want a typical customer to be doing anyway. Especially since much of this stuff they will need to redo each and every time the data mover is updated.

On the other hand, let me just repeat that we can work out of the box with any minimal Linux install out there, in a fully supported fashion. So naturally, the best approach would be to understand how is their Linux environment different. If it helps, our support can tell you based on the logs what exact operation fails in their case, and you can go from there.

[remosito]

I am getting some data mover installation errors as well.

albeit very different ones:

24.06.2021 15:16:23 Error Installing Veeam Data Mover service Error: tar: vddk_6_7/lib64/libgvmomi.so: Wrote only 9216 of 10240 bytes
tar: vddk_6_7/lib64/libstdc++.so.6: Cannot write: No space left on device
tar: vddk_6_7/lib64/libcrypto.so.1.0.2: Cannot write: No space left on device
tar: vddk_6_7/lib64/libz.so.1: Cannot write: No space left on device
tar: vddk_6_7/lib64/libffi.so.5: Cannot write: No space left on device
tar: vddk_6_7/lib64/libsqlite3.so.0.8.6: Cannot write: No space left on device
tar: vddk_6_7/lib64/libgcc_s.so.1
tar: vddk_6_7/lib64/libgvmomi.so: Wrote only 9216 of 10240 bytes
tar: vddk_6_7/lib64/libstdc++.so.6: Cannot write: No space left on device
tar: vddk_6_7/lib64/libcrypto.so.1.0.2: Cannot write: No space left on device
tar: vddk_6_7/lib64/libz.so.1: Cannot write: No space left on device
tar: vddk_6_7/lib64/libffi.so.5: Cannot write: No space left on device
tar: vddk_6_7/lib64/libsqlite3.so.0.8.6: Cannot write: No space left on device
tar: vddk_6_7/lib64/libgcc_s.so.1: Cannot write: No space left on device
tar

since update to V11 our backups to the synology nas (linux server based repository) are much slower. (50-100MB/s vs 500+ MB/s with V10 on active fulls)

(Just restored an old Veeam V10 backup... and tried...for some reason hotadd didnt work. but so much has changed in our network since that backup (new server that hosts veeam virtual machine and all servers that are backed up. failover is a different one now too. So not really surprised. With nbd backup speed on that V10 restored vm was 200MB/s. When I did it with our active V11 and switching to nbd/network on proxy. It was 50MB/s... )

Can it be that V11 Veeam and proxy are not 100% compatible with V10 mover on the synology repository? Resulting in that much slower speed?

[Mildur]

Can it be that V11 Veeam and proxy are not 100% compatible with V10 mover on the synology repository?

As far as I know, V10 DataMover will never work with another build or Veeam Version.
Every Veeam VBR component needs to be on the same Version and build number.

[remosito]

Backups to that repository still work. Just much slower than they used to with V10

[remosito]

Follow up:

Exposed the relevant Directories on the Synology NAS via NFS to the Backup Server and created a Veeam NFS Repository in Veeam.

Did a VeeamZip of our AD VM onto that NFS Repository and it ran through at 300MB/s (Bottleneck Source)
Doing a VeeamZip onto the original Linux Server Repository on the Synology and it's currently running at 20MB/s (Bottleneck Target)

I guess we'll be switching over to using NFS. Need to check how incrementals run on it. And our Tape Job.

Anybody know if existing Backup Chains can be kept when switching Access from Linux Repository to NFS Repository pointing to the same place?

[remosito]

Switching existing Chains to the new NFS repository worked like a charm.

Incrementals work much better again too:

Exchange Server Incremental:
Veeam V10 and Synology as Linux Repository: 6minutes
Veeam V11 and Synology as Linux Repository: 100minutes (I kid you not)
Veeam V11 and Synology as NFS Repository: 24 Minutes

still much slower than V10 with Linux Repository. But we can live with that. Ample fast for our chains not stepping on each others toes....

[Gostev]

Did you check if your Synology box meets the minimum system requirements for RAM? Perhaps there's a lot of swapping going, which slows everything down.

[remosito]

It's a ds3615xs with 16GB of RAM. Both CPU and RAM hardly get usage....

It has a 10bit eth card.


Another workaround besides nfs repository we have considered is use the NAS with iscsi and pass the disk space to the esxi where our veeam backup server is running on. And have Veeam use that....

How is speed of that versus nfs and vs fully working linux repository on NAS (like what we had with Veeam V10)

[Mildur]

pass the disk space to the esxi where our veeam backup server is running on.

My recommendation, Connect it better directly to a vm. An vcenter/esxi Admin can delete the vmdks on the datastore, if you connect the iscsi to the esxi environment. Someone with no access to the backup server can delete your backups this way. Simple delete the vmdk.

Speed of synthetic Fulls will be much better, because you can leverage FastClone Feature with refs (windows vm) or xfs (linux vm) block cloning. I‘m not sure about the speed with incrementals. They should be ok, if you have a normal stable network (1gbit/10gbit) and not much changed data.

[Zew]

I thought using a Synologgy NAS directly hasn't been support in the longest time.. like this really old post:
veeam-backup-replication-f2/backups-to- ... t=Synology

I've always used a dedicated linux server (added to Veeam as a managed server) that connects to a Synology NAS.

Is this setup still good? I wasn't aware of this Data Mover change, is that something anyone else needs to consider in their infra?

[Mildur]

It is supported. I don‘t see why not. If I read your linked topic correctly, it was slower as a NFS Share. But with FastClone, it should be faster on synthetic fulls.

You need to properly size it of course.
Example: Don‘t use a cheap home user NAS as a backup repo for productive environment, if you want to be issue free.

I've always used a dedicated linux server (added to Veeam as a managed server) that connects to a Synology NAS.

That would be the best way of course it‘s more secure as connected to a vm

[remosito]

My recommendation, Connect it better directly to a vm. An vcenter/esxi Admin can delete the vmdks on the datastore, if you connect the iscsi to the esxi environment. Someone with no access to the backup server can delete your backups this way. Simple delete the vmdk.

Speed of synthetic Fulls will be much better, because you can leverage FastClone Feature with refs (windows vm) or xfs (linux vm) block cloning. I‘m not sure about the speed with incrementals. They should be ok, if you have a normal stable network (1gbit/10gbit) and not much changed data.

thanks a bunch for the reply

the vcenter/esxi admin would be me too...so not really a problem.

But I think esxi might halt my veeam backup vm if the iscsi datastore it uses disconnects temporarily (nas update, switch reboot, ....).
Windows will hopefully handle this more gracefully...

[TitaniumCoder477]

If you're going to connect to the VMware host via NFS, probably should use NFSv4.1 with multipathing. Works very well, unless you have an unstable environment (i.e. in my experience, mainly power outages that can lead to improper shutdown of the environment and corruption on any file system but seems especially bad for NFS datastores). https://www.stephenwagner.com/2019/08/1 ... tipathing/

[b.vanderhorst]

Hi, our recommended setup now from my company:

Linux (ubuntu) vm on the host/san, from the vm an iscsi connection to the nas. Iscsi volume formatted as XFS with reflink. VM added to Veeam as managed server.
This levers the fast clone, dedup from reflink. It is fast because computing is done on the VM instead of the nas. It works for VMware (hot-add) and Hyper-V.
With iscsi you can lever from multiple connections to your nas (no LAG/LACP) if connected properly.

The vm can be small:
4 vCpu (no need for more)
50 GB hdd (can be smaller)
2+ vNics for iscsi and Veeam connection
iscsi volume with xfs and reflink (can be as big as you want)

Gives us speed, dedup and fast clone.

[kgajda]

Exchange Server Incremental:
Veeam V10 and Synology as Linux Repository: 6minutes
Veeam V11 and Synology as Linux Repository: 100minutes (I kid you not)
Veeam V11 and Synology as NFS Repository: 24 Minutes

still much slower than V10 with Linux Repository. But we can live with that. Ample fast for our chains not stepping on each others toes....

I can confirm this too. (the Linux-based repository slowed down badly, after switching from 9.x (and 10.x) into 11.x. I have to switch to NFS (or SMB).

PS: I noticed that in this linux-based repo, the process named "veeamagent" caused 100% disk utilisation during transfer (the "wa" column in top command) and do very little peformance and the same time (50-70 MB/s instead of 350-450 like in 9.x or 10.x version).

[kgajda]

I have to mention that UseUnbufferedAccess=0 and DisableHtAsyncIo=1 do the trick and performance got back to levels like before

[TitaniumCoder477]

Update on this Veeam/Synology incompatibility...

A couple months ago we upgraded all our clients' BNRs to 11.0.1.1261 to address the CVEs (CVE-2022-26500, CVE-2022-26501). The symptom described in this forum post didn't change. That is, the "/opt/veeam/transport/veeamtransport: error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory" symptom remained.

However, when we recently upgraded all our clients' Synology NAS devices to DSM 7.1-42661 Update 1 to address the recent CVEs (CVE-2022-23125, CVE-2022-23122, CVE-2022-0194), the integration completely broke. That is, Veeam would say, "Timeout to start agent," and all jobs to the repo would fail.

During investigation, I could not resolve the issue, so I returned to the original symptom--of the missing ACL package--and decided to test deploying it manually. It works, but I have no idea if a DSM update will require reapplying the fix.

Basically, the solution involves (1) downloading the Debian 64bit ACL package, (2) extracting the .deb file using 7-zip, (3) re-zipping as tar, (4) uploading to your NAS via SCP or the web UI, (5) SSH'ing to your NAS and extracting the tar file, (6) setting permissions, (7) creating soft links, and then (8) removing the /opt/veeam folder, if it exists. After this is done, you can then access VBR > Backup Infrastructure > Managed Servers > Linux > right-click the NAS in question > Properties. In the wizard, make sure Non-root > Elevate account privileges automatically is configured for the account you are using to access the NAS. Then click through to finish out the wizard. Veeam will re-create the /opt/veeam folder, and you should be good to go!

Here is the bash script I created to do most of this work for me:

Code: Select all

#!/bin/bash

echo "Extracting tar file..."
tar xvf libacl1_2.2.53-10_amd64.tar -C /

echo "Setting permissions..."
chown -R root:root /usr/lib/x86_64-linux-gnu
chmod -R 755 /usr/lib/x86_64-linux-gnu

echo "Creating soft links..."
ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1 /usr/lib/libacl.so.1
ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1.1.2253 /usr/lib/libacl.so.1.1.2253

echo "Removing /opt/veeam folder per https://forums.veeam.com/veeam-backup-replication-f2/failed-to-get-server-fingerprint-there-is-no-certificate-t74902.html"
rm -R /opt/veeam

[kvomax79]

Hi TitaniumCoder477,

We are having the exact same issue after updating Synology NAS devices to DSM 7.1-42661 Update 1

For your fix:
For step 1, where are you downloading the Debian 64bit ACL Package? I am guessing you are getting it from here: http://ftp.debian.org/debian/pool/main/ ... _amd64.deb
For step 4, what location are you uploading the tar file to?
For steps 5-8, it seems like you are using bash script mentioned below:
#!/bin/bash

echo "Extracting tar file..."
tar xvf libacl1_2.2.53-10_amd64.tar -C /

echo "Setting permissions..."
chown -R root:root /usr/lib/x86_64-linux-gnu
chmod -R 755 /usr/lib/x86_64-linux-gnu

echo "Creating soft links..."
ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1 /usr/lib/libacl.so.1
ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1.1.2253 /usr/lib/libacl.so.1.1.2253

echo "Removing /opt/veeam folder per veeam-backup-replication-f2/failed-to-g ... 74902.html"
rm -R /opt/veeam

[kvomax79]

So I got it working after downloading it from here: http://ftp.debian.org/debian/pool/main/ ... _amd64.deb

Once you have the .deb file, use 7zip to extract the file which will give you a "data.tar" file. I didnt have to extract the data.tar file and re-tar it. Log into you synology console via the GUI and open "File Station" . Right click on the location where you want to upload it and click on "Upload to..."

The rest of the steps are the same as what "TitaniumCoder477" mentioned above. One thing to remember is that you might have to append sudo to the command so that system prompts for the root password.

For the command "sudo tar xvf libacl1_2.2.53-10_amd64.tar -C /" replace "xvf libacl1_2.2.53-10_amd64.tar" with whatever file you uploaded to the synology NAS.

Here are the all commands you need to run in SSH

#!/bin/bash

echo "Extracting tar file..."
sudo tar xvf libacl1_2.2.53-10_amd64.tar -C /

echo "Setting permissions..."
sudo chown -R root:root /usr/lib/x86_64-linux-gnu
sudo chmod -R 755 /usr/lib/x86_64-linux-gnu

echo "Creating soft links..."
sudo ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1 /usr/lib/libacl.so.1
sudo ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1.1.2253 /usr/lib/libacl.so.1.1.2253

echo "Removing /opt/veeam folder per veeam-backup-replication-f2/failed-to-g ... 74902.html"
sudo rm -R /opt/veeam

[TitaniumCoder477]

Apologies. I was trying to cram a 5 day week into 3 days last week! Glad you filled in the gaps and got it working! We have all our clients' Synology NAS devices set to auto patch/upgrade (minor versions), so we'll know soon enough whether any of that breaks/undoes the work. That said, it takes less than 5 minutes to apply the fix, so not to bad.

[B-C]

thank you guys for this

- just saved me a lot of hand wringing and curse words!
haven't been digging into my Veeam for over a year!

[B-C]

installed clean - but getting
Date Time :: Processing <VMName> Server - VM Error: Socket has been forcibly closed. Failed to recover connection.

on a gig to Synology not exactly sure whats up

[TitaniumCoder477]

All VMs or just some in the job? Intermittent or constant? Also, please share screenshot or copy & paste of full log line w/ error message and details redacted if needed.

[Bourome]

Hi all, I follow this topic more than 1 year.
As for you, i use Synology as Linux repo. Since one year, no problem to use without datamover and immutable.
Yesterday, Syno 7.1-42661 Update 1 break all my backup with the error "Timeout to start agent".
I follow your miracle process and ...grrr... no work for me.
-tar extracted
-Permissions ok
-Link OK
-i try reboot nas...
When i launch the wizard in VBR, i have exactly the same error "mkdir: cannot create directory '/opt': Permission denied" and my backup always fail with "Timeout to start agent".
It seems the process dont working for me... ? maybe an error on my side?
Last year, i put this configuration on my Synology. Maybe there is a problem at this moment ?

- Control Panel/Terminal & SNMP: Enable SSH
- Click on "Advanced Settings" and change the cipher strength to "Low"
- Control Panel/User/Advanced: Enable the user home service..
- Package Center: Search for Perl.
Many thanks to you.

PS : I paste you my command in cli :
admin@RS2418-DC04:/volume1/homes$ sudo tar xvf data.tar -C /
./
./usr/
./usr/lib/
./usr/lib/x86_64-linux-gnu/
./usr/lib/x86_64-linux-gnu/libacl.so.1.1.2253
./usr/share/
./usr/share/doc/
./usr/share/doc/libacl1/
./usr/share/doc/libacl1/changelog.Debian.gz
./usr/share/doc/libacl1/changelog.gz
./usr/share/doc/libacl1/copyright
./usr/lib/x86_64-linux-gnu/libacl.so.1
admin@RS2418-DC04:/volume1/homes$ sudo chown -R root:root /usr/lib/x86_64-linux-gnu
admin@RS2418-DC04:/volume1/homes$ sudo chmod -R 755 /usr/lib/x86_64-linux-gnu
admin@RS2418-DC04:/volume1/homes$ sudo ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1 /usr/lib/libacl.so.1
admin@RS2418-DC04:/volume1/homes$ sudo ln -sf /usr/lib/x86_64-linux-gnu/libacl.so.1.1.2253 /usr/lib/libacl.so.1.1.2253
admin@RS2418-DC04:/volume1/homes$ sudo rm -R /opt/veeam