Thanks. I’m not sure if FUSE mountpoints appear as directories to whatever IsBlockDevice() calls. I think they might do as they’re backed by block devices rather than being device nodes themselves.
Maybe it would be better for path exclusions to be done first and thereby prevent attempts to access anything that won’t be backed up but there may be good reasons for why it works the current way.
I’d prefer not to explicitly include directories as there is a risk that this will get out of date and I want everything in /home backed up.
It seems it should be possible to disable the creation of these problematic directories in the xrdp config so I’ll probably try that first
There’s probably something similar to what the stat command runs somewhere underneath.
You could try that to see what it looks like and whether you get any unexpected access errors.
We have to wait for a developer opinion on approaches, I think.
What user is Duplicati running as? Most likely guesses would be martin or root.
FUSE access checking is different from on the local filesystem, to avoid accidents.
Basically if you can avoid an early warning, then you might get to intended exclude.
But there are other consequences to changing FUSE access, so please think it out.
It’s running as root, I just installed the latest RPM.
I think it was a poor decision by xrdp to create these files in home directories. It looks like the change to /etc/xrpd/sesman.ini has worked. The directory hasn’t appeared again after a restart, which should stop the warnings.
The idea was to defer the filter check until later, as it is usually the slowest operation.
The error message “FileAccessError” is not reported there there, it happens when trying to access the file later. If that line failed, you would see “PathProcessingErrorBlockDevice” in the error message.
