"Zugriff verweigert" bei manchen Dateien

[Benares]

Ich habe in letzter Zeit ein etwas merkwürdiges Problem:
Manche Dateien lassen sich einfach nicht aufs NAS kopieren. Es kommt die Fehlermeldung "Zugriff verweigert".

Die meisten dieser Dateien stammen aus dem Internet, meist PDFs oder ZIPs und haben deshalb meist noch das Attribut "... stammt aus unsicherer Quelle ..." gesetzt. Aber auch, wenn ich das zurücksetze, klappt es nicht. Am Namen liegt es auch nicht, umbenannt oder kopiert nach xxx.pdf und dann aufs NAS kopieren, geht auch nicht. Erst wenn ich xxx.pdf in den Editor (Notepad++) nehme und mit "Speichern unter" als yyy.pdf speichere (Inhalt ist laut. "fc" weiterhin identisch), kann ich yyy.pdf aufs NAS kopieren. Natürlich ist das Zielverzeichnis immer das gleiche. Noch komischer: In andere Zielverzeichnisse kann ich beide Dateien kopieren, in andere nur die yyy.pdf.

Es muss also irgendwie an den Attributen oder an den Rechten der Quelldatei liegen. Wenn ich aber die Eigenschaften von xxx.pdf und yyy.pdf vergleiche, sind beide (bis aufs Datum natürlich) absolut identisch. Gibt es noch weitere, ggf. unsichtbare Attribute?

Ich weiß nicht, ob es an Windows 10 oder an der aktuellen DSM-Version liegt. Ich versteh es einfach nicht.

Hat einer von euch dazu eine Idee?

Edit:
Wenn ich die Datei xxx.pdf mit der Filestation aufs NAS lade (ja, das geht), dann mit dem Explorer wieder zurückkopiere, kann ich sie anschliessend auch mit dem Explorer wieder hochladen. Es betrifft im übrigen alle Dateien, die ich nach der Migration auf Windows 10 aus dem Internet heruntergeladen habe. Lokal erstellte Dateien gehen. Ich tippe mal auf irgendwelche versteckten Dateiattribute unter Windows 10, die das Verhalten bewirken. Ich hab auch mal ein Ticket bei Synology aufgemacht.

Edit2:
Also es scheint reproduzierbar sein. Wenn ich eine Datei (Beispiel AVM-Beta-Firmware als ZIP) aus dem Internet lade und zunächst lokal kopiere, kann ich sie später nicht aufs NAS kopieren (Access denied). Ein direkter Download aufs NAS funktioniert dagegen. Ich versteh es nicht.

 

[Benares]

Auch wenn bislang noch niemand helfen konnte, bin ich wohl nun doch dem Geheimnis auf die Spur gekommen.

Beim Kopieren vom PC auf das NAS über den Explorer ensteht im Zielverzeichnis ein unsichtbares @eaDir-Verzeichnis, in dem auch nach dem Kopiervorgang pro kopierter Datei eine Datei mit den Namen <Dateiname>@SynoEAStream mit jeweils 174 Bytes liegen bleibt. Bei weiteren Kopiervorgängen zum gleichen Ziel kommt es dann teilweise zu dem oben beschriebenen Effekt. Löscht man das @eaDir-Verzeichnis, ist die Welt wieder in Ordnung.

Ich denke nicht, dass es etwas mit der Medienindizierung zu tun hat, da der Zielfolder nicht zu den indizierten Verzeichnissen gehört (gewöhnlicher Share "Backup"). Es ist wohl eher ein Bug im Samba-Server.

Könntet ihr mal schauen, ob ihr auch solche @eaDir-Reste und *@SynoEAStream-Files auf euren normalen Shares findet?

cd /volume1
find . -name '*@SynoEAStream' -exec ls -als {} \;

 

[stefan_lx]

Die Dateien haben was mit Mac OS zu tun ...

Wenn man so eine @SynoEAStream-Datei oder eine @SynoResource-Datei (dazu später) anschaut, dann steht was von Mac OS X drin, bei den Stream-Dateien der mp3s kann man sogar den cover-Namen erkennen... und nein, ich nutze keinen Mac...

Trotzdem finde auch ich diese Dateien in den Shares, allerdings nur mit den dazugehörigen "Original-Dateien".. das System, wann die @SynoEAStream-Dateien entstehen, erschließt sich mir aber nicht...
Im music-Ordner habe ich die @SynoEAStreams, in einem nicht indizierten Ordner mit mp3s finde ich ebenso @SynoEAStreams...
Andere Ordner die mit smb befüllt worden sind, haben die @SynoEAStreams nicht...
Es scheint sich immer um Mediendateien zu handeln, die die Dateien verursachen...
Bei zip, exe oder anderen Dateien gibt es dagegen eine @SynoResource-Datei (manchmal).

Dass die Dateien entstehen liegt nicht an Windows 10 oder an ntfs-Streams (also den versteckten Attributen), weil ich z.B. kein ntfs nutze, aber die Dateien trotzdem finde...

Hast du vielleicht die Original-Dateien (irgendwann mal) nicht über smb gelöscht/verändert? Das Löschen und Ändern von Dateien über smb oder die Filestation löst normalerweise das gleiche für die @eaDirs aus, wenn aber per Skript auf der Shell das Löschen oder Ändern stattgefunden hat, könnten die @eaDirs noch übriggeblieben sein...

Stefan

 

[Benares]

Hallo Stefan,

danke für deine Antwort.

Ich habe keine MACs. Aber ich den iTunes-Server auf der DS aktiv und auch iTunes auf dem PC installiert.

Ich habe mittlerweile all meine Shares bereinigt. Auf den "normalen" Shares hab ich die @eaDir-Verzeicnisse komplett gelöscht, bei "photo" nur die *@SynoEAStream-Dateien darin.
Trotzdem finde ich nach Kopiervorgängen auch auf den normalen Shares immer wieder solche @eaDir-Verzeichnisse mit *@SynoEAStream-Dateien vor, meist nachdem ich recht viele Dateien auf einmal aufs NAS kopiert habe. Ob es einen Zusammenhang mit Medien-Dateien gibt, muss ich mal beobachten. Natürlich sind bei den Backups (Share "Backup") meiner PCs auch einige Mediendateien dabei. Ich hab aber auch schon @SynoEAStream-Dateien von PDFs und ZIPs gefunden.

Als ich die unter #1 beschriebenen Probleme hatte, habe ich natürlich auch in die /var/log/samba/log.smbd geschaut. Da fand ich dann Meldungen wie

../source3/modules/synovfs_stream.c:642: [2015/09/04 12:09:06.783771, vfs 0, pid=23697] SYNOSmbOpenSynoStream
  synovfs_eaopen(EASTREAM, pcxxx/data/Download/AVM/Fritz!Box7490/FRITZ.Box_7490_Labor.113.06.36-31214.image, EASTREAM, C+RW) failed, Permission denied, [0x0000 (null):0]

PDFs waren auch viele dabei.

Ich tippe daher eher auf einen Bug im Samba-Server. Ich werde das mal beobachten. Ein Ticket bei Synology hab ich auch schon eröffnet.

Edit:
Ich eben übrigens nochmal ein einziges PDF in ein Verzeichnis auf dem Backup-Share kopiert und zack, war wieder ein @eaDir-Verzeichnis mit einer @SynoEAStream-Datei vorhanden. Wenn ich "strings" darauf loslasse, kommt

Mac OS X
ATTR
Zone.Identifier
[ZoneTransfer]
ZoneId=3

Auch bei anderen Dateitypen (.z.B. rar, exe) passiert das ab und zu, aber nicht immer. Das lustige ist, wenn ich die Datei wieder lösche, ist auch das @eaDir-Verzeichnis wieder weg.

 

[dil88]

Ich habe die Dateien auch (947 Stück). Viele enthalten die Daten, die Du unter Edit aufgeschlüsselt hast. Die Datei zu einer exportierten Email enthält aber auch den Absender beispielsweise.

 

[Benares]

Hallo dil88,

dank dir für die Info - also scheinbar kein neues Problem, nur noch nicht aufgefallen.

Bin mal gespannt, was Synology dazu sagt - wenn die überhaupt noch was dazu sagen. Mein Ticket ist schon einige Tage alt - keine Reaktion bislang.

 

[stefan_lx]

ob da noch viel Antwort kommt? die sind doch schon mit DSM 6.x beschäftigt
http://download.synology.com/download/securityscan/DSM6_X/

Da diese Dateien bei selber gebauten rsyncs stören, interessiert mich das aber auch...

Stefan

 

[Benares]

Hälst du das wirklich für einen Vorboten von DSM6? Ich weiss nicht so recht. Hat doch vermutlich wohl eher mit dem kürzlich aufgetauchten Problem mit der Isolierung von zip zu tun, oder?

 

[stefan_lx]

der Vorbote ist eher der Verzeichnisname
auch im spk-Verzeichnis tut sich was und ein Verzeichnis NoteStation-Offline gibt es auch....

Stefan

 

[Benares]

Na ja. Dass im September wieder was fällig ist, ist ja bekannt. Die sollen lieber mal die noch vorhandenen Probleme lösen, anstatt ständig neue Probleme zu schaffen - meine Meinung.

 

[stefan_lx]

da hast du nicht ganz Unrecht ... aber leider ist das inzwischen normal... Hauptsache mehr Features, ob die nun alle funktionieren, ist dann eine andere Sache... aber das ist ein generelles Problem, da ist Synology nicht allein, es gibt "Software-Riesen", die Betas teuer verkaufen.. aber bevor es jetzt offopic wird, hören wir besser auf

Stefan

 

[Benares]

Hier die ultimative Antwort vom Synology-Support zum Thema

It seems that I found the cause of the problem.

There are a lot of *@SynoEAStream files with 174 Bytes in @eaDir folders in nearly every folder on all of my shares. I deleted them and all @eaDir folders outside of the photo share. Now it works again.
Seems to be a bug in your samba server.
Please fix it asap.

Die Antwort:

Ihr Anliegen bzw. Ihren Wunsch werde ich unmittelbar an unsere Entwickler weiterleiten.

Mal sehen. Ich rechne, ehrlich gesagt, nicht mit Ergebnissen/Lösungen.