Martin Horský's questions

I'm trying to restore preexisting files on a DFS share on Server2012r2. No matter what I do, I get this response. This occurs even if I use -RestoreToPath or if I try to run it with the local admin account.

PS E:\> Restore-DfsrPreservedFiles -Path "E:\share\DfsrPrivate\PreExistingManifest.xml" -RestoreToOrigin -Force

Restore-DfsrPreservedFiles : Access to path E:\share\DfsrPrivate\PreExisting\username\Data aplikací\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar was denied.

The issue seems to be the fact, that the administrator doesn't have the permissions to access some AppData stuff. However the DFS service moved it to PreservedFiles without an issue, so there has got to be some way of doing this.

I need for Restore-DfsrPreservedFiles to work in a sudo rsync -a kind of way.

Or at least make it move anything it can access while ignoring errors.

I had a folder shared on my windows network. I wanted that folder to by replicated with DFSR, so I created a target folder in a DFS namespace and a replication group with it. One of the targets was the original share with files in it, and I wanted those files to be replicated. The other targets were new empty folders.

The folder in the DFS namespace was empty (makes sense, I just created it, and it probably haven't replicated yet). However, in a few minutes, the original folder was empty too. Seems windows decided, that the "newer" empty fodlders were "newer", therefore replicated that. But now the files are gone and even testdisk can't find them. They aren't in DfsrPrivate or anywhere else.

Is it possible, and if so how, to recover them?

After updating from Stretch to Buster and moving from iptables to nftables, the nft command doesn't process any given command except for list, which doesn't print anything.

The input nft flush ruleset prints:

Error: Could not process rule: Invalid argument
flush ruleset
^^^^^^^^^^^^^^
Error: Could not process rule: Invalid argument
flush ruleset
^^^^^^^^^^^^^^

nft create table inet filter

Error: Could not process rule: Invalid argument
create table inet filter
^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Could not process rule: Invalid argument
create table inet filter
^^^^^^^^^^^^^^^^^^^^^^^^^

Even with the initial config in the debian package, it prints an error for each line in it.

nft -f /etc/nftables.conf

/etc/nftables.conf :

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;
    }
    chain forward {
        type filter hook forward priority 0;
    }
    chain output {
        type filter hook output priority 0;
    }
}

/etc/nftables.conf:3:1-14: Error: Could not process rule: Invalid argument
flush ruleset
^^^^^^^^^^^^^^
/etc/nftables.conf:5:1-2: Error: Could not process rule: Invalid argument
table inet filter {
^^
/etc/nftables.conf:6:15-19: Error: Could not process rule: Invalid argument
    chain input {
                 ^^^^^
/etc/nftables.conf:9:15-21: Error: Could not process rule: Invalid argument
    chain forward {
                 ^^^^^^^
/etc/nftables.conf:12:15-20: Error: Could not process rule: Invalid argument
    chain output {
                 ^^^^^^
/etc/nftables.conf:3:1-14: Error: Could not process rule: Invalid argument
flush ruleset
^^^^^^^^^^^^^^
/etc/nftables.conf:5:1-2: Error: Could not process rule: Invalid argument
table inet filter {
^^
/etc/nftables.conf:6:15-19: Error: Could not process rule: Invalid argument
    chain input {
                 ^^^^^
/etc/nftables.conf:9:15-21: Error: Could not process rule: Invalid argument
    chain forward {
                 ^^^^^^^
/etc/nftables.conf:12:15-20: Error: Could not process rule: Invalid argument
    chain output {
                 ^^^^^^

Distro: Debian GNU/Linux 10 (buster)

nft: nftables v0.9.0 (Fearless Fosdick)

On SuperMicros site in OS support, there are boards that support RHEL of version X but not CentOS of version X and vice versa. I have encountered such problems my self. My question is how and why is this even possible, when CentOS is functionally identical to RHEL. And whether there is any workaround?