Robocopy ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory

Lanciando per la prima volta questo semplice script con Robocopy:

> robocopy %SOURCE% %DESTINATION% /COPYALL /MIR /ZB /R:3 /W:5 /LOG:%LOGFILE%

dove:

  • %SOURCE% era un percorso locale (Server Windows), ad esempio C:\Test
  • %DESTINATION% era un percorso di rete, nello specifico, una cartella di un NAS, ad esempio \\MyNAS1\share1\Test
  • %LOGFILE% era il percorso in cui aveva il mio file di log

mi sono accorto che erano state copiate soltanto cartelle e sottocartelle vuote.

Analizzando il log mi sono accorto dei seguenti errori:

[...]

    New File 6148 .DS_Store
2015/12/24 10:41:56 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory C:\\Test\\
A required privilege is not held by the client.
    New File 41.3 m test.doc
2015/12/24 10:41:56 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory C:\\Test\\
A required privilege is not held by the client.
    New File 659 README.txt
2015/12/24 10:41:56 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory C:\\Test\\
A required privilege is not held by the client.
    New File 17920 TESTxlsx.xlsx
2015/12/24 10:41:56 ERROR 1314 (0x00000522) Copying NTFS Security to Destination Directory C:\\Test\\

[...]

lo stesso errore per ogni file.

Per risolvere il problema ho modificato lo script togliendo l’opzione /COPYALL e mettendo al suo posto /COPY:DAT, così:

> robocopy %SOURCE% %DESTINATION% /COPY:DAT /MIR /ZB /R:3 /W:5 /LOG:%LOGFILE%

Molto probabilmente il NAS che ha un sistema UNIX al suo interno, non riesce a mantenere le informazioni di sicurezza, proprietari e auditing che vengono passate rispettivamente con le opzioni S, O e U.

Attenzione: nel mio caso, la rimozione delle opzioni faceva al caso mio perché non avevo la necessità di mantenere quelle informazioni nel mio backup. In caso contrario, consiglio di cercare altrove la causa del problema.

Note utili tratte dal sito ufficiale

  • /COPYALL : Copy ALL file info (equivalent to /COPY:DATSOU).
  • /COPY:copyflag[s] : What to COPY (default is /COPY:DAT)
    (copyflags : D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

Link utili su Robocopy per capire e approfondire la sintassi

QNAP Formatting failed (Cannot unmount disk)

In un NAS QNAP ho dovuto aggiungere due hard disk da 4 TB.

Dopo aver inserito il primo, ho notato che la formattazione manuale falliva. Accedendo ai System Logs ho trovato le seguenti righe:

... 19:37:17 [Single Disk Volume: Drive 1] Formatting failed(Cannot unmount disk).
... 19:37:15 [Single Disk Volume: Drive 1] Formatting failed.
... 19:37:13 [Single Disk Volume: Drive 1] Start formatting.

Per risolvere il problema ho:

  • spento il NAS
  • staccato il primo disco nuovo che avevo inserito
  • collegato tale disco ad un altro PC utilizzando un adattatore USB
  • avviato quel PC con una distribuzione di Linux (ho usato una versione live di Ubuntu)
  • avviato il programma GParted Partition Editor
  • cancellato tutte le partizioni dal disco finché non ho visto tutto lo spazio “unallocated”
  • avviato il Terminal e lanciato il comando (ATTENZIONE: USATE QUESTO COMANDO SOLO SE SAPETE COSA STATE FACENDO, altrimenti rischiate di effettuare cancellazioni non volute. Dovete modificare /dev/sdb in base a come viene visto il vostro disco esterno. Lo vedete comodamente su GParted):
sudo dd if=/dev/zero of=/dev/sdb bs=446 count=1
  • smontato il disco dal PC e montato sul NAS
  • effettuato le stesse operazioni sull’altro disco nuovo che dovevo inserire e l’ho montato sul NAS
  • acceso il NAS

Entrambe le formattazioni sono avvenute con successo. Questo il risultato dei log:

23:17:26 [Single Disk Volume: Drive 2] Formatting completed.
23:08:32 [Single Disk Volume: Drive 2] Start formatting.
23:05:15 [Single Disk Volume: Drive 2] Start initialization.
22:54:03 [Single Disk Volume: Drive 1] Formatting completed.
22:43:47 [Single Disk Volume: Drive 1] Start formatting.
22:40:25 [Single Disk Volume: Drive 1] Start initialization.
22:34:32 Drive 2 plugged in.
22:00:24 Drive 1 plugged in.

Eccezione da HRESULT: 0x800A03EC PowerShell

Dopo aver eseguito questo comando PowerShell che incolla una formula dentro una cella di un file Excel:

$excelObject = New-Object -ComObject Excel.Application

$targetWorkbook = $excelObject.Workbooks.Open($myFile)

$firstSheet = $targetWorkbook.Worksheets.Item(1)

$firstSheet.Cells.Item(6,2).Formula = "=SE(VAL.ERRORE(MEDIA(..."

appariva il seguente errore:

Eccezione da HRESULT: 0x800A03EC
In riga:1 car:1
+ $firstSheet_N.Cells.Item(6,2).Formula = "=SE(VAL.ERRORE(MEDIA(..."
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [], COMException + FullyQualifiedErrorId : System.Runtime.InteropServices.COMExcep tion

Dopo qualche ricerca e qualche intuizione, ho ricondotto l’errore alle impostazioni internazionali di Excel.

Ho modificato l’ultima riga nel modo seguente:

$firstSheet.Cells.Item($r,2).FormulaLocal = "=SE(VAL.ERRORE(MEDIA(..."

Come si vede, al posto di .Formula ho usato .FormulaLocal che fa funzionare il passaggio di stringhe con le impostazioni internazionali locali (inclusi i separatori,…).

Ho rilanciato lo script e ha funzionato tutto correttamente.

[Errno 14] curl#56 – “Network error recv()” – impostare proxy yum Fedora Core

Se dopo aver lanciato yum update:

[usertest@fedoratest ~]$ sudo yum update
[sudo] password for usertest:

Compare:

Loaded plugins: langpacks, presto, refresh-packagekit
fedora/metalink | 33 kB 00:00
http://fedora.mirror.garr.it/mirrors/fedora/linux/releases/15/Everything/i386/os/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()"
Trying other mirror.
ftp://ftp.ciril.fr/pub/linux/fedora/linux/releases/15/Everything/i386/os/repodata/repomd.xml: [Errno 14] curl#7 - "Couldn't connect"
Trying other mirror.
http://mirror.nl.leaseweb.net/fedora/linux/releases/15/Everything/i386/os/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()"
Trying other mirror.
[...]

Potrebbe essere necessario impostare il vostro proxy nel file yum.conf. Quindi andiamo ad editare tale file:

[usertest@fedoratest ~]$ sudo gedit /etc/yum.conf

e aggiungiamo le seguenti righe al suo interno, dopo il tag [main]:

proxy=http://proxy.mioDominio.it:portaDelProxy
proxy_username=nomeUtente
proxy_password=miaPassword

Es:
[main]
proxy=http://proxy.gabriele.it:8080
proxy_username=gabriele
proxy_password=My_V3rY_Str0Ng_P4$$wW0rD!
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
...

N.B. 1: ricordatevi che il file yum.conf è aperto in lettura a tutti gli utenti… la password è scritta in chiaro…

N.B. 2: a quanto parte Fedora Core 15 ha un bug per l’impostazione del proxy. Leggi qui.

SIOCSIFNETMASK No such device

Mentre avviavo una Debian, ho visto dei messaggi che mi hanno insospettito:

SIOCSIFNETMASK: No such device
SIOCSGIFADDR: No such device
eth0: ERROR while getting interface flags: no such device
eth1: ERROR while getting interface flags: no such device

Facendo:

$ ifconfig

veniva visualizzata solo l’interfaccia loopback, mentre con:

$ ifconfig -a

non c’erano più la eth0 e la eth1, ma la eth2 e eth3 (Figura 1):

Andando a vedere il log: /var/log/messages ho notato:

kernel: [..] udev: renamed network interface eth0 to eth2
kernel: [..] udev: renamed network interface eth1 to eth3

Successivamente ho controllato il file:

/etc/udev/rules.d/70-persistent-net.rules

e ho visto le seguenti righe:

# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*c",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*d",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*6",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*7",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

A questo punto sono andato a controllare (sempre da ifconfig -a, vedi Figura 1) i MAC delle schede, ho commentato le prime due righe (con MAC diverso) e ho modificato le ultime due mettendo “eth0” e “eth1” al posto di “eth2” e “eth3” (Figura 2):

# PCI device 0x8086:0x1076 (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*c",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*d",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*6",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*7",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Dopo aver fatto ciò, ho riavviato ed è tornato tutto come prima.