@olivierlambert I have seen that part of the documentation and it did not contain a solution for me. I also talked to the community on the Teleport Slack and some staff member tried to solve it, but was unable to. So I hope the Teleport discussion forum on github will lead to some solution, so for not.
So lets please keep this post open as someone here who is using Teleport might see it and answer, while that person may or may not follow the Teleport discussion on github.
@stephane-m-dev understood. My suggestion regarding the different behavior (does not work with disk share, does work with user share) on unraid would be to put this in a "tip" in the documentation section about setting up Remotes.
@stephane-m-dev well, have you tried this on an unraid server with a disk share? if not, you are still missing my point.
the disk share (there the error occurs):
"/mnt/disk3" -fsid=87,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)
the user share (here it works):
"/mnt/user/backup" -fsid=91,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)
please also do not overlook the other problem with the full backup mode when encryption is used: "Trying to add data in unsupported state" (see above)
@stephane-m-dev the folder was positively empty, I explicitly removed all files before adding it as remote. Have you read what I wrote about different share types in unRAID?
@stephane-m-dev the path exists but it was empty.
@daniel-grimm definitely not related to cloud in my case!
I am now also seeing the "Trying to add data in unsupported state" problem,
see this thread: https://xcp-ng.org/forum/post/84594
That did never occur when the remote used for this backup was not encrypted.
I am seeing this problem on a encrypted NFS remote (server runs unRAID), too. Only one VM out of 6 VMs that get full backup. Always the same VM shows this error. The same schedule for these VMs did not produce this error on an unencrypted NFS remote on the same server. Also, using delta backup instead full backup on the same encrypted remote does not produce this error.
"stack": "Error: Trying to add data in unsupported state\n at Cipheriv.update (node:internal/crypto/cipher:181:29)\n at /etc/xen-orchestra/@xen-orchestra/fs/dist/_encryptor.js:52:22\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async pumpToNode (node:internal/streams/pipeline:135:22)"
Are there any news regarding this issue?