Archiv Bit unter Samba?

Hallo,

eigentlich sollte das Archiv-Bit gespeichert werden.
Seit den neuesten Firmware V3.2.x wird es nicht im Execute-Bit der Dateien gespeichert, sondern es wird mit in den erweiterten Attributen des Datei-System geschrieben.

Hast du Zugriff auf dein NAS über Telnet oder der SSH-Konsole (Putty) ?
Dort könntest du überprüfen, ob das Filesystem entsprechend (user_xattr) gemountet wurde:

[~] # mount
/dev/md0 on /share/MD0_DATA type ext3 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered)

Stefan

Hallo, ich habe bei meinem TS410 (3.2.3 Build 0212T) das gleiche Problem mit dem Archivbit.

mount bring folgende Meldung:

[/] # mount
/proc on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,size=32M)
none on /proc/bus/usb type usbfs (rw)
/dev/sda4 on /mnt/ext type ext3 (rw)
/dev/md9 on /mnt/HDA_ROOT type ext3 (rw)
/dev/md0 on /share/MD0_DATA type ext3 (rw,usrjquota=aquota.user,jqfmt=vfsv0,data
=writeback)
tmpfs on /.eaccelerator.tmp type tmpfs (rw,size=32M)
nfsd on /proc/fs/nfsd type nfsd (rw)

Was muss ich jetzt machen, damit das Archiv Bit gesetzt wird ?

Hallo zusammen,

erster Post hier. Ich würde mich auch gerne in Die Diskussion bzgl. "fehlender" user_xattr einhängen.

Zitat von "Eraser-EMC2-"

[...]
Dort könntest du überprüfen, ob das Filesystem entsprechend (user_xattr) gemountet wurde:

Code

[~] # mount
/dev/md0 on /share/MD0_DATA type ext3 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered)

Gibt es die Möglichkeit, bei einem schon komplett formatierten und mit Daten bestückten TS-439 Pro II die Extended Attributes (user_xattr) nachträglich "zu aktivieren" (hier spricht der absolute Unix Neuling :oops: )? Ist das Fehlen dieser ein Versäumnis der Erstinstallation (Haken in der Konfigurationsoberfläche übersehen, o.ä.), oder warum "sind die nicht da"?

Dank und Gruß!

Inzwischen bin ich mir nicht mehr sicher, ob die Änderung mit Windows-Attributen in der Firmware Version 3.2 oder 3.3 geändert wurde.
Bei der Firmware 3.3 steht in der "/etc/config/smb.conf" ua. :

store dos attributes = yesmap archive = nomap system = nomap hidden = no

Der Befehl zum aktivieren der ExtendedAttribute auf der Konsole lautet zB.:

tune2fs -o +user_xattr /dev/sda3

Danach noch remount ausführen

-o remount /share/HDA_DATA

für /dev/sda3

Hallo,

gibts hier keine weiteren User welche das gleiche Problem mit dem Archiv Bit haben ? ( ohne Archiv Bit haut das mit einer inkrementellen Sicherung auf dem NAS nicht hin )

Zitat

Code: Alles auswählen
store dos attributes = yes
map archive = no
map system = no
map hidden = no

Der Befehl zum aktivieren der ExtendedAttribute auf der Konsole lautet zB.:

Code: Alles auswählen
tune2fs -o +user_xattr /dev/sda3
Danach noch remount ausführen

Code: Alles auswählen
-o remount /share/HDA_DATA für /dev/sda3

Alles anzeigen

das hat bei mir nicht funktioniert !

Ich wäre über jeden Tipp dankbar

Hallo erstmal...,

wir haben das gleiche Problem vie Farz » Mi 17. Nov 2010, 12:09

Wir arbeiten in einer Workgroup und erstellen bzw. bearbeiten unsere Dateien im Userverzeichnis der QNAP (Netzlaufwerk).
Ein Client mit XP-Profesionell SP3 soll das Backup vom QNAP (TS209 | v3.3.0 0924) via Netzwerk übernehmen.
Als Backup-Software dient eine inkrementelle Sicherung mit z-dbackup auf Basis des Archiv-Bit von Windows auf eine externe Platte.

Fehlerbeschreibung:
Neue Dateien erhalten immer das Archivbit werden also auch immer mit gesichert (erwünscht).
Bei veränderten Files durch Anwendungen wie AutoCAD LT oder Office 2003 wird es ebenfalls gesetzt (erwünscht).

Nur bei Veränderungen der Files durch Office 2007 und 2010 wird das Archivbit auf der QNAP nicht gesetzt (unerwünscht).
Bei Veränderungen der Files durch Office 2007 und 2010 lokal unter Windows wird das Archivbit jedoch normal gesetzt.
Hinweis, wir arbeiten mit Office 2007 und Office 2010 im Kompatibilitätsmodus.

Hat jemand eine Idee oder gar ne Lösung für mich?

icqtoni