DiskStation DS418j のクチコミ掲示板

ファイルコピーした時のファイルの作成日時につきまして

[今日は寒い。]

DS418Jをデータのバックアップを目的に購入したのですが、当方の環境では、次のような現象が発生して困っている状況です。

Robocopyでファイルコピーをすると、ファイルの作成日時が、コピーを実行した日時に戻るという症状です。

動作環境
PC:Windows 10 Pro 1903, IP:192.168.1.1
NAS:DS418J, IP:192.168.1.2
PCとNASはスイッチHUBを介して接続されている状況で、他の機器はHUBに接続されていません。
PCはOSをクリーンインストールして他にはアプリをインストールしていない状況です。
コピー元のフォルダ(C:\Temp)には1,000個のファイルを格納しておきます。
コピー先には、共有Testに、あらかじめフォルダ(Test01〜Test10)を準備しておきます。

実行するコマンド

1回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
2回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
3回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
4回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
5回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
6回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
7回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
8回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
9回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
10回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT

コピーを実行した直後のフォルダにあるファイルの作成日時をエクスプローラーで確認すると、
コピー元のファイル作成日付と同じになっているのですが、コピーを1回目から10回目ぐらいまで
続けると、1回目にコピーしたフォルダ(Test01)にあるファイルの作成日付が、コピーを実行した
日時に戻ってしまいます。
1回目にコピーしたフォルダ(Test01)のファイル作成日付が、元に戻とは限らず、他のフォルダの場合もあります。

他の環境では発生しないのか、使用方法がよくないのか、ご教示いただけますと助かります。

よろしくお願いいたします。

書込番号：23035107

[tanetty]

＞今日は寒い。さん

こんばんは。

当方、synologyを持っていないうえ、原因も見当がつきません。
このため、以下は役に立たない情報だと思うので、たいへん恐縮ですが。

＞Robocopyでファイルコピーをすると、
＞ファイルの作成日時が、コピーを実行した日時に戻る

＞コピー元のファイル作成日付と同じになっている
＞コピーを実行した日時に戻ってしまいます。

謎現象ですね…。 /COPYにTつけてるので、OKそうなものなのに。
コピー直後はOKなのに、しばらく経つとNGになってしまう…と。
しかも、NGになる場合とならない場合がある(＝再現性なし)…と。
Synologyが何かをきっかけに、勝手に書き換えちゃうのでしょうか？？？

原因がさっぱり思いつかないのですが、
次のことを試してみてはいかがでしょうか。
「もし治ったらもうけもん」ぐらいの気持ちの話になりますけども。

(a) robocopyのオプションを、念のためフルフルにしてみる。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

(b) 各コマンド間の実行に、時間を空けてみる。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /COPY:DAT
が完了してから10秒後に
robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\” /COPY:DAT
を実行….といった感じで。

(a)は「オプション足りない問題」か否かの切り分けに
(b)は「タイミング悪いかも問題」か否かの切り分けに
いちおうはなるかな…と

あと、/LOG:ファイル名 をつけてログを残して精査すると、
もしかしたら何かわかるかも？

以上、役に立たない情報ばかりで、失礼いたしました。m(_ _)m

書込番号：23035229

[とにかく暇な人]

＞今日は寒い。さん
多分、この問題は解決不能だと思いますので、例えば、7zipで
https://www.lisz-works.com/entry/compression-7zip-command
のようにしてコピーするフォルダーやファイルをアーカイブファイルにしてRobcopyでコピーすればよいのではないですか。
そうすれば、コピー時間が早くなるし、タイムスタンプの問題もなくなると思いますよ。
因みに、コピーで問題が発生するファイルは仮想マシンがらみのファイルではないですよね。

書込番号：23035261

[Excel]

念のために確認してもらいたいことがあるっす。

おんなじことを、NASへのコピーではなく、元ファイルとおんなじドライブ内の「別フォルダー」にした場合には、どうなるっすか？

書込番号：23035436

[galaxy1]

�@PC→NASでのrobocopyの話だと思いますが、どこかで
�ANAS→PC　の同期が走っていませんか
この製品の説明でいたるところに「PCやラップトップでデータ同期をリアルタイムで設定して、システムのクラッシュやランサムウェア攻撃からデータを守ります。 」との記載があり気になりました

書込番号：23035613

[LsLover]

『コピーを実行した直後のフォルダにあるファイルの作成日時をエクスプローラーで確認すると、
　コピー元のファイル作成日付と同じになっているのですが、コピーを1回目から10回目ぐらいまで
　続けると、1回目にコピーしたフォルダ(Test01)にあるファイルの作成日付が、コピーを実行した
　日時に戻ってしまいます。』

「コピーを実行した直後」：「コピー元のファイル作成日付と同じになっている」

しかし、

「コピーを1回目から10回目ぐらいまで続ける」：「コピーを実行した日時に戻ってしまいます。」

という状況のようですが、ある程度の時間経過後にファイル作成日付が書き換えられるということでしょうか?

書込番号：23035688

[たく0220]

＞今日は寒い。さん

こんにちは。
SynologyのNASは持っておりませんので確証はありませんが

ファイルシステムはext4だと思いますが、mount時のオプションで"user_xattr"ついているのかと
Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。

Samba3ぐらいから作成日時も拡張属性で扱う範囲内かと思うので、その辺の確認からかな…

SSHが使えるなら、該当ファイルを"getfattr"コマンドで
"user.DOSATTRIB"の存在の確認。
なければ、どこかのタイミングかで消された可能性があるので
メーカーか代理店に聞くぐらいか、所有しているユーザーがいそうなSynology日本語フォーラムで聞くのが良いかもしれません。

書込番号：23036165

[今日は寒い。]

＞tanettyさん
このにちは。返信ありがとうございます。

ご提案の(a)(b)を実行してみました。

>(a) robocopyのオプションを、念のためフルフルにしてみる。
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

注意: セキュリティがコピーされない可能性があります - コピー先で固定 ACL がサポートされ ていない可能性があります。
と表示されてRobocopyが実行できませんでした。
このメッセージが何かわからないので後で調べようと思います。

>(b) 各コマンド間の実行に、時間を空けてみる。
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /COPY:DAT
>が完了してから10秒後に
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\” /COPY:DAT
>を実行….といった感じで。

コピー先を、"Test11"から"Test13"まで指定して約10秒間隔で実行しましたところ、
3003個のファイルにうち、154個のファイルが、コピーした日時になり、残りはコピー元の
ファイル作成日時のままになります。
コピーした日付時刻に戻ったファイルはすべて"Test12"フォルダの中にあります。

ログは、

合計 コピー済み スキップ 不一致 失敗 Extras
ディレクトリ: 1 0 1 0 0 0
ファイル: 1001 1001 0 0 0 0
バイト: 1000.00 m 1000.00 m 0 0 0 0
時刻: 0:00:31 0:00:31 0:00:00 0:00:00


速度: 33242750 バイト/秒
速度: 1902.165 MB/分
終了: 2019年11月10日 14:07:40

と、なっています。

よろしくお願いいたします。

書込番号：23038620

[今日は寒い。]

＞tanettyさん

こんにちは。

すいません。このにちは。になっていました。

訂正させていただきます。

書込番号：23038631

[今日は寒い。]

＞とにかく暇な人さん

こんにちは。返信ありがとうございます。

＞多分、この問題は解決不能だと思いますので、例えば、7zipで
＞https://www.lisz-works.com/entry/compression-7zip-command
＞のようにしてコピーするフォルダーやファイルをアーカイブファイルにしてRobcopyでコピーすればよいのではないですか。

このような使い方があったのですね。ありがとうございます。
コマンドプロンプトは、どうも苦手で、いつもは、CopyExtやBackupというフリーソフトを使用して、
USB外付けHDDにバックアップしていまして、この時は、作成日時が変更されることはないです。

何とか、この問題が解決できればと考えているのですが・・・。

＞因みに、コピーで問題が発生するファイルは仮想マシンがらみのファイルではないですよね。
仮想マシンがらみのファイルではないです。

よろしくお願いいたします。

書込番号：23038660

[今日は寒い。]

＞Excelさん
こんにちは。返信ありがとうございます。

＞おんなじことを、NASへのコピーではなく、元ファイルとおんなじドライブ内の「別フォルダー」にした場合には、どうなるっすか？

下記のコマンドで実行してみました。

robocopy "c:\temp\" "c:\temp1\" /COPY:DAT
robocopy "c:\temp\" "c:\temp2\" /COPY:DAT
robocopy "c:\temp\" "c:\temp3\" /COPY:DAT

コピー先の作成日時は、すべてのファイルがコピー元と同じになっていいます。

よろしくお願いいたします。

書込番号：23038674

[今日は寒い。]

＞galaxy1さん

こんにちは。返信ありがとうございます。

＞�ANAS→PC　の同期が走っていませんか

DS418Jには、パッケージセンターというのがありまして、そこには、
File StationとUniversal Searchがインストールされています。
この2個のパッケージは、アンインストールできないようです。

また、PCにも同期をとるようなソフトをインストールしていない状況です。

ですので、勝手に同期しないと思うのですが・・・。

よろしくお願いいたします。

書込番号：23038700

[今日は寒い。]

＞LsLoverさん

こんにちは。返信ありがとうございます。

＞という状況のようですが、ある程度の時間経過後にファイル作成日付が書き換えられるということでしょうか?

現状を報告します。

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT

を実行すると、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
を実行した時点では、Test01内のファイルは、コピー先もコピー元も同じファイル作成日時で、
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
を実行した時点で、Test01内のファイルを確認すると、コピー先のファイル作成日時が、
コピーを実行したファイル日時になりま。

今までの実行結果ですと、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test11\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test12\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test13\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test14\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test15\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test16\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test17\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test18\" /COPY:DAT

を実行しますと、コピー先もコピー元も同じファイル作成日時のファイルは、

Test15フォルダ内に、1001個中　722個
Test16フォルダ内に、1001個中1001個
Test17フォルダ内に、1001個中1001個
Test18フォルダ内に、1001個中1001個

残りのファイルは、コピーを実行した日時に戻っています。

よろしくお願いいたします。

書込番号：23038752

[とにかく暇な人]

＞今日は寒い。さん
ファイルの日付が不正確になるのは、DS418jのファームか何かのバグだと思うので、Synologyに聞くしかないと思えてきたのですが、どうでしょうか。

書込番号：23038762

[今日は寒い。]

＞たく0220さん

こんにちは。返信ありがとうございます。

＞ファイルシステムはext4だと思いますが、mount時のオプションで"user_xattr"ついているのかと
＞Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。

ファイルシステムの事はよくわからないのですが、とりあえず、SSHで接続してみました。

$cat /stc/fstabの実行結果を貼り付けます。(貼り付けて良いかどうかわかりませんが。)

none /proc proc defaults 0 0
/dev/root / ext4 defaults 1 1
/dev/vg1000/lv /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,relatime 0 0

"getfattr"コマンドは、
-sh: getfattr: command not found
で使えないようです。

$cat /etc/samba/smb.confの実行結果を貼り付けます。(これも貼り付けて良いかどうかわかりませんが。)

[global]
printcap name=cups
winbind enum groups=yes
include=/var/tmp/nginx/smb.netbios.aliases.conf
min protocol=SMB2
security=user
local master=no
realm=*
passdb backend=smbpasswd
printing=cups
max protocol=SMB3
winbind enum users=yes
load printers=yes
workgroup=WORKGROUP

これで何か分かりますでしょうか。他に調べ方がありましたら、ご教示をお願いいたします。

＞Synology日本語フォーラムで聞くのが良いかもしれません。
Synology日本語フォーラムというのがあるのですね。ありがとうございます。

よろしくお願いいたします。

書込番号：23038834

[Chubou]

一つ確認したい点があります。

ファイルの「作成日時」が書き換わると言われておりますが、ファイルのタイムスタンプには色々なものがあります。
「日付時刻」「作成日時」「更新日時」「撮影日時」などです。（「撮影日時」は画像ファイル、ピクチャ・フォルダ等の場合のみ該当）

エクスプローラーの表示設定によって、タイムスタンプの表示内容や表示の意味が変わったりもします。
エクスプローラーの「表示」タブ - 「詳細」の表示にした後、「列の追加」アイコンをクリックして、表示項目にチェックを入れることで表示する「日時」を選ぶことができます（添付画面参照）。
添付画面では、「日付時刻」「作成日時」「更新日時」にチェックを入れて、表示している状態です。

そこで、スレ主さんに質問です。
スレ主さんは「作成日時が変化する」と言われていますが、変化するのは本当に「作成日時」なのでしょうか？

変化するのが本当に「作成日時」であれば、原因を想像しにくいのですが、もし、変化するのが「作成日時」ではなく「更新日時」であれば、状況から考えて DS418J 上で何らかの自動更新処理が働いているのではないかと疑うことができます。

書込番号：23038879

[たく0220]

＞今日は寒い。さん

確認と情報ありがとうございます。

現象を伺っているとキャッシュが一回りして内容が変わってしまったような現象ですね。
PCを一度再起動してみた場合ではどうですか？
作成日時が元ファイルと同じファイルが残っていますか？

＞$cat /stc/fstabの実行結果を貼り付けます。(貼り付けて良いかどうかわかりませんが。)
mount での確認の方が良いかもしれません。

QNAP TS-231Pの例(該当箇所以外は省略)
# mount
/dev/mapper/cachedev1 on /share/CACHEDEV1_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,d

"getfattr"は使えませんでしたか…
お手数かけました。残念。


＞$cat /etc/samba/smb.confの実行結果を貼り付けます。(これも貼り付けて良いかどうかわかりませんが。)

Sambaの"testparm"コマンドに詳細(-v)と"grep"コマンドをパイプ(|)で連携させて確認してみてください。
何も表示されない場合は、設定がされてない可能性があります。

・"testparm"コマンド使えるか確認方法
which testparm

[実行例]
# which testparm
/usr/bin/testparm

・testparm
("Press enter to see a dump of your service definitions"と表示されたらEnterを押す)
testparm -v | grep "store dos attributes"

[実行例]
# testparm -v | grep "store dos attributes"
Load smb config files from /etc/config/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Processing section "[Multimedia]"
Processing section "[Download]"
*** 省 略 ***

EDEV1_DATA/.samba/state should have permissions 0755 for browsing to work

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

store dos attributes = Yes


＞注意: セキュリティがコピーされない可能性があります - コピー先で固定 ACL がサポートされ ていない可能性があります。

Synologyサポートセンター : 共有フォルダに権限を割り当てる
https://www.synology.com/ja-jp/knowledgebase/DSM/help/DSM/AdminCenter/file_share_privilege#t2
の「Windows ACL 権限のカスタマイズ」を確認してみてください。

私のNASでは面倒なので拡張ACLはOFFにしてます ^^;

以下も参考になるかと思います。
http://www.nslabs.jp/samba-windows-acl.rhtml

書込番号：23038894

[今日は寒い。]

＞とにかく暇な人さん

こんにちは。返信ありがとうございます。

＞ファイルの日付が不正確になるのは、DS418jのファームか何かのバグだと思うので、Synologyに聞くしかないと思えてきたのですが、どうでしょうか。

実のところ、Synologyのサポートには、10月16日から10回以上にわたり、やり取りをしていまして、Synologyから要求で、パケットキャプチャのデータを提供したり、デスクトップの共用の提供をしたりしてきました。

しかしながら、何回も訴えましたが、Synokogy側は、当方のPCの問題であって、DS418Jには、問題ないとの回答なのです。

ですので、Synokogy側に「皆さんに聞いてみます。」と伝えた上で、皆さんに状況を、ご質問させていただいた次第です。

DS418Jは2台所有していまして、1台はデータが保存されていて、作成日時が化けてしまって、どこにもバックアップもなく、作成日時を戻せなくて、大変困っています。あと1台は、データを移動させて、検証している状況です。

よろしくお願いいたします。

書込番号：23038903

[たく0220]

＞今日は寒い。さん

補足ですが"stat"というコマンドでファイルを確認することもできます。
Windows(NTFS)の作成日時にあたるのは"Birth:"という項目になるのですが
私のでは対応してないのか、表示されてません。

# stat 1572727499.zip
File: "1572727499.zip"
Size: 7767 Blocks: 24 IO Block: 4096 regular file
Device: fc00h/64512d Inode: 2168 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 0/ admin) Gid: ( 0/administrators)
Access: 2019-11-10 15:41:30.000000000
Modify: 2019-11-03 06:18:20.000000000
Change: 2019-11-03 06:25:55.000000000

書込番号：23038930

[とにかく暇な人]

＞今日は寒い。さん
本問題の再現環境を作って、Synologyに送って実行して確認してもらったらどうですか。

書込番号：23038943

[今日は寒い。]

Test15フォルダ内の状況

＞Chubouさん

こんにちは。返信ありがとうございます。

＞スレ主さんは「作成日時が変化する」と言われていますが、変化するのは本当に「作成日時」なのでしょうか？

「作成日時」になります。フォルダ内の状況を添付致します。ご確認いただけますでしょうか。

更新日付は変化していません。

よろしくお願いいたします。

書込番号：23038963

[今日は寒い。]

＞たく0220さん

こんにちは。返信ありがとうございます。

＞PCを一度再起動してみた場合ではどうですか？
＞作成日時が元ファイルと同じファイルが残っていますか？

PCを再起動してみました。結果は同じで、コピー先もコピー元も同じファイル作成日時のファイルは、

Test15フォルダ内に、1001個中　722個
Test16フォルダ内に、1001個中1001個
Test17フォルダ内に、1001個中1001個
Test18フォルダ内に、1001個中1001個

となっています。

＞mount での確認の方が良いかもしれません。

#mountを実行しましたので結果を貼り付けます。
/dev/mapper/vg1000-lv on /volume1 type ext4 (rw,relatime,synoacl,stripe=48,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)


＞Sambaの"testparm"コマンドに詳細(-v)と"grep"コマンドをパイプ(|)で連携させて確認してみてください。
testparmコマンドを実行しましたので結果を貼り付けます。

# testparm -v | grep "store dos attributes"
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Can't find include file /var/tmp/nginx/smb.netbios.aliases.conf
Processing section "[Test]"
/etc/samba/smb.reserved.conf not found
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

store dos attributes = No


＞Synologyサポートセンター : 共有フォルダに権限を割り当てる
＞以下も参考になるかと思います。

サイトをご提供いただき、ありがとうございます。勉強します。

よろしくお願いいたします。

書込番号：23039057

[tanetty]

＞今日は寒い。さん

こんばんは。
さっそく実験してくださったのですね。
誠にありがとうございます。
お手数かけ、申し訳ありませんでした。



�@ フルフル時のセキュリティエラーについて

「セキュリティがコピーされない可能性があります」については、
コマンドプロンプトを「管理者として実行」なさってないようでしたら、
お試しいただく価値はあるかと思います。

https://www.adminweb.jp/command/ini/index12.html

それでもダメなら、以降はCOPYの後ろのSOU部分は、削除してください。
こんな感じで(↓)。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DAT /DCOPY:T

※Windows上で持っていた権限情報をコピーするのが、SとOとUです。
　Linux上で意味がなければ、スルーしてくれるかな？思っていたのですが、
　もしかしたら違うのかもしれませんね。スミマセン。



�A 時間をおいたときでもダメな件

＞コピー先を、"Test11"から"Test13"まで指定して約10秒間隔で実行しましたところ、
＞3003個のファイルにうち、154個のファイルが、コピーした日時になり、
＞残りはコピー元のファイル作成日時のままになります。

「一部がコピーした日時」になってしまっている状態から、
何回か/MIRつきで走らせるとどうなるでしょうか。

こんな感じで(↓)
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

/MIRがついていると、完全に差分コピーとなります。つまり、
・タイムスタンプが同じファイルは、スルーします。
・タイムスタンプが異なるファイルのみ、上書きしてくれます。
・差分のみの処理なので、２回目以降は初回に比べ、格段に早く終了します。

/MIRつきでくりかえし実行して、もしうまくいくのなら、
解決策にはなりませんが、回避策にはなるかと思います。
robocopyを/MIRつきで数回くりかえすバッチファイルをつくっておけば、
NGだったファイルだけ再実行してくれますので。



�B アンチウィルス容疑者説

あと、「アンチウィルス系が悪さしてないか？」ということも、疑っています。
もしPC側・Synology側に、アンチウィルスが入っていたら、ですが。
それぞれ一時的に停止して、どうなるか？
を試してみると、その切り分けになるかと思います。

書込番号：23039094

[今日は寒い。]

＞とにかく暇な人さん

こんばんは。返信ありがとうございます。

＞本問題の再現環境を作って、Synologyに送って実行して確認してもらったらどうですか。

再現環境を作って、Synologyからリモートデスクトップでアクセスしてもらって確認してもらいました。

Synology側の確認は、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT

だけを実行して、「問題なし」の判断です。

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
を実行した時点で、Test01内のファイルを確認すると、コピー先のファイル作成日時が、
コピーを実行したファイル日時になる。

というのは、何度指摘しても確認しようとしません。

これが現状です。

本問題で、10回以上Synologyとのやり取りしており、もう疲れてきました。
(愚痴ってしまいました。すみません。)

よろしくお願いいたします。

書込番号：23039183

[Chubou]

今日は寒い。さん

> 「作成日時」になります。フォルダ内の状況を添付致します。ご確認いただけますでしょうか。
> 更新日付は変化していません。

なるほど。
「更新日時」は変わっていない。「作成日時」が変わっているのですね。
2019/11/10 15:03 がコピー作業を行った日時ということですか。

結果として、「更新日時」より「作成日時」の方が新しい日付になっていますね。 これは、確かにおかしいですね。
ファイルシステムに何か問題がありそうです。
可能性としては、やはり DS418j のファイルシステムに問題が…。

書込番号：23039206

[LsLover]

『コピー先もコピー元も同じファイル作成日時のファイルは、

　Test15フォルダ内に、1001個中　722個
　Test16フォルダ内に、1001個中1001個
　Test17フォルダ内に、1001個中1001個
　Test18フォルダ内に、1001個中1001個

　残りのファイルは、コピーを実行した日時に戻っています。』

「Test15フォルダ内に、1001個中　722個」以外とTest1[8-10]フォルダ内のファイルでコピーを実行した日時に戻るようですね。
規則性が絞りにくいですね。

改善するか分かりませんが、以下を試しては如何でしょうか?

当方では、以下のようなパラメータでローカルディスクのディレクトリをNASの共有フォルダにバックアップしています。
ローカルディスクのディレクトリ内の更新されたファイルのみNASの共有フォルダにコピーします。初回のみ、ローカルディスクのディレクトリ内のすべてのファイルをNASの共有フォルダにコピーします。

robocopy.exe /E /MIR /NFL /NDL /NP C:\[ローカルディレクトリ] \\[NASのIPアドレス]\[共有フォルダ]

書込番号：23039225

[たく0220]

＞今日は寒い。さん

確認と情報ありがとうございます。

結果を見ると、従来の拡張属性での方法ではなく
Synology独自の方法を取られてる感じはします。

調べてる時に下記Qiitaの記事がヒットしました。
Qiita : Mac の Go で birth time を取得する
https://qiita.com/hiokidaichi/items/26890e7da566cb3a4121

「Mac 以外では・・ ?」の項目でSynologyのNASからcrtime(作成日時)を参照できたそうです。
ということは、ext4のinodeにcrtime(作成日時)を記録していると考えられます。

ただし、ext4はcrtime(作成日時)を元々は扱っていませんでした。
ですのでまだSambaや他のソフトウェアとの連携に問題が残っている可能性は十分に考えられます。

Windowsのエクスプローラー上だけcrtime(作成日時)が読めない場合があるか
Sambaからの書き込み時にcrtime(作成日時)が反映されない場合があるのどちらかだと思います。

まずはSSHで現状ファイルがどのように記録されているかも確認された方が良いかと思います。

# ls -i foo
のところから(fooはファイル名)でinodeの番号がわかります。

# debugfs -R "stat <27204>" /dev/md0

"stat <27204>" は先ほどのinodeの番号を<>内に
/dev/md0 は /dev/mapper/vg1000-lv
に変更して試してみてはどうでしょうか。

書込番号：23039275

[今日は寒い。]

コピー元	再起動前	再起動後

＞みなさま

たくさんのご返信ありがとうございます。

みなさまからいただきました情報をもとに、当方で色々と確認致しました。
新たに判明しました状況を報告致します。

動作環境は当方が書き込みをさせていただいた時点と同じになります。
ウィルス対策ソフトは別途インストールしておらずDefenderが動作しています。
DS418Jにはウイルス対策パッケージをインストールしていない状況です。

次の手順で操作しますと、全てのファイルがコピーした日時に戻りました。

1.Robocopyコマンドでコピーする。
robocopy "c:\temp\" "\\192.168.1.2\Test\Test20\" /MIR /COPY:DAT /DCOPY:T

2.ファイルの作成日時を確認する。
→コピー元のファイル作成日時と同じになっている。

3.DS418Jを再起動する。

4.1で実行したファイルの作成日時を確認する。
→\\192.168.1.2\Test\Test20フォルダ内のすべてのファイルがコピーを実行した日時に戻る。


次のように確認しました。

1.あらかじめ作成日時がコピーを実行した日時のファイル情報を確認。
(とりあえず1つだけ)

\\192.168.1.2\Test\Test15フォルダ内の11.datファイル
作成日時:2019-11-10 15:03 (エクスプローラー上の作成日時)

#ls -i 11.dat
129906413 11.dat

# debugfs -R "stat <129906413>" /dev/mapper/vg1000-lv
debugfs 1.42.6 (21-Sep-2012)
Inode: 129906413 Type: regular Mode: 0777 Flags: 0x80000
Generation: 271770684 Version: 0x00000000:00000000
User: 1024 Group: 100 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2048
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5dc7a81e:3eeac980 -- Sun Nov 10 15:03:10 2019
atime: 0x5dc2dff0:00000000 -- Thu Nov 7 00:00:00 2019
mtime: 0x5dbb0718:00000000 -- Fri Nov 1 01:08:56 2019
crtime: 0x5dc7a81e:37c3b44c -- Sun Nov 10 15:03:10 2019
Size of extra inode fields: 36
Extended attributes stored in inode body:
archive_version = "52 25 01 00 01 00 00 00 " (8)
EXTENTS:
(0-255):3415296-3415551

2.Robocpyを実行してコピーを実行
robocopy "c:\temp\" "\\192.168.1.2\Test\Test20\" /MIR /COPY:DAT /DCOPY:T

3.あらたにコピーしたファイルの情報を確認。
(とりあえず1つだけ)

\\192.168.1.2\Test\Test20フォルダ内の1.datファイル
作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
→コピー元のファイル作成日付と同じ。

# ls -i 1.dat
129892355 1.dat

debugfs -R "stat <129892355>" /dev/mapper/vg1000-lv
debugfs 1.42.6 (21-Sep-2012)
Inode: 129892355 Type: regular Mode: 0777 Flags: 0x80000
Generation: 3144990274 Version: 0x00000000:00000000
User: 1024 Group: 100 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2048
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5dc8e45c:ac7928c0 -- Mon Nov 11 13:32:28 2019
atime: 0x5dc2dff0:00000000 -- Thu Nov 7 00:00:00 2019
mtime: 0x5dbb0716:00000000 -- Fri Nov 1 01:08:54 2019
crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019
Size of extra inode fields: 36
Extended attributes stored in inode body:
archive_version = "52 25 01 00 01 00 00 00 " (8)
EXTENTS:
(0-255):68608-68863

4.DiskStation Manager (DSM)上で他のファイルの作成日時がわかるように画面コピーする

5.DS418Jを再起動
→DiskStation Managerから[再起動]を実行

6.1で実行したファイルの作成日時を確認

\\192.168.1.2\Test\Test20フォルダ内の1.datファイル
作成日時:2019/11/11 13:32 (エクスプローラー上の作成日時)
→コピーを実行した日時に戻りました。

\\192.168.1.2\Test\Test15フォルダ内の11.datファイル
作成日時:2019-11-10 15:03 (エクスプローラー上の作成日時)
→コピーを実行した日時のまま

7.DiskStation Manager (DSM)上でファイルの作成日時がわかるように画面コピーする

以上になります。

画面コピーを添付しておきます。


この症状は、DS418Jの不具合のように思えてなりません。
もしかしたら、当方だけではないような気もします。
SynologyのNAS所有者の方(DS418J以外の機種でもいいです)で、
同じ症状になるか試していただけますと幸いです。

よろしくお願いいたします。

書込番号：23040621

[今日は寒い。]

＞みなさま

もうひとつ情報を、ご提供させていただきます。

それは、DS418Jに搭載しているHDDになります。

当方、Seagate ST4000VN008 - 2DR166を4台搭載していて、
(Synologyのサイトで、現状、テストおよび検証済みHDDとなります。)

RAIDタイプ : Synology Hybrid RAID(SHR
ストレージプール : 1
ステータス : 正常

となっています。

よろしくお願いいたします。

書込番号：23040642

[たく0220]

＞今日は寒い。さん

こんばんは。確認ご苦労様です。

画像なのですが、再起動前と再起動後が同じ画像のように見えます
アップロード時に間違われてませんか？


＞3.あらたにコピーしたファイルの情報を確認。

で"debugfs"コマンドで確認された作成日時(crtime)ですが

＞ crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019

ですので、"2019/11/11 13:32:28" がコピーされたファイル(1.dat)に記録されている作成日時です。

＞作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
＞→コピー元のファイル作成日付と同じ。
との事でしたので、この時点ではDSMの"File Station"上では正常(コピー元と同じ)であって
DS418Jの再起動後に異常(コピーを実行した日時に)に戻ったという事ですか？


＞この症状は、DS418Jの不具合のように思えてなりません。

ext4でcrtimeを変更出来るメソッドは今のところ無いと個人的に認識していたので
Sambaの設定見たときは、出来るようになったの？と疑問があったのですが…
WindowsとLinuxでは作成日時に対する扱い(考え方)が違うので、その違いをサポートが理解してない可能性もあり、
不具合というより、仕様(元々出来ない)という事もありえそうです。

書込番号：23039057で、コピー先もコピー元も同じファイル作成日時のファイルがあったと思いますが
DS418Jの再起動後ですが、エクスプローラー上で作成日時の変化はありましたか？

書込番号：23040927

[今日は寒い。]

再起動前	再起動後

＞たく0220さん

こんばんは。返信ありがとうございます。

＞画像なのですが、再起動前と再起動後が同じ画像のように見えます
＞アップロード時に間違われてませんか？

ご確認ありがとうございます。確かに間違っておりました。
再度アップロードいたします。

よろしくお願いいたします。

書込番号：23041058

[とにかく暇な人]

＞今日は寒い。さん
DiskStation DS418jがLinixベースで動作していれば、作成日時をRobocopyでコピーするのは不可能だから、ある意味では、作成日時がコピー日時と同じになるのは仕様と考えるしかないですよね。
ただし、作成日時がコピーされたように見えるのは、明らかなバグなので、この事はSynologyにバグとして認識してもらわなければならないですよね。
そこで画像を見て気になったのですが、WindowsのExplorerとFile Staitionで作成日を見た場合に差異はないのでしょうか。
もし、Explorerで見て作成日時が全てコピー日時と等しければ、DiskStation DS418jのバグではなくて、File Staitionのバグという事になると思いますので、どうか確認をお願いします。

書込番号：23041141

[今日は寒い。]

＞たく0220さん

こんばんは。返信ありがとうございます。

＞＞ crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019
＞ですので、"2019/11/11 13:32:28" がコピーされたファイル(1.dat)に記録されている作成日時です。

なるほど、ご教示ありがとうございます。

＞＞作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
＞＞→コピー元のファイル作成日付と同じ。
＞との事でしたので、この時点ではDSMの"File Station"上では正常(コピー元と同じ)であって
＞DS418Jの再起動後に異常(コピーを実行した日時に)に戻ったという事ですか？

そうなります。

＞ext4でcrtimeを変更出来るメソッドは今のところ無いと個人的に認識していたので
＞Sambaの設定見たときは、出来るようになったの？と疑問があったのですが…
＞WindowsとLinuxでは作成日時に対する扱い(考え方)が違うので、

なるほど、ご教示ありがとうございます。勉強になります。

＞不具合というより、仕様(元々出来ない)という事もありえそうです。
Synologyサポートには「仕様ですか？」と問い合わせましたが、ファイル作成日時はSynology側で異常は認められず、当方のPC等が原因との見解です。
ですので、仕様(元々出来ない)という事はないように思います。
購入した当時は、異常はなかったような気もします。(今回の症状に気が付いていなかっただけ？かも。)

＞書込番号：23039057で、コピー先もコピー元も同じファイル作成日時のファイルがあったと思いますが
＞DS418Jの再起動後ですが、エクスプローラー上で作成日時の変化はありましたか？

DS418Jの再起動後、作成日時がコピー元と同じファイルは、20,020個中0個で、コピー先もコピー元も同じファイル作成日時のファイルは一つもありません。

よろしくお願いいたします。

書込番号：23041170

[今日は寒い。]

再起動前	再起動後

＞とにかく暇な人さん

こんばんは。返信ありがとうございます。

＞そこで画像を見て気になったのですが、WindowsのExplorerとFile Staitionで作成日を見た場合に差異はないのでしょうか。
＞もし、Explorerで見て作成日時が全てコピー日時と等しければ、DiskStation DS418jのバグではなくて、File Staitionのバグという事になると思いますので、どうか確認をお願いします。

次のコマンドを実行ました。

1.robocopy "c:\temp\" "\\192.168.1.2\Test\Test22\" /MIR /COPY:DAT /DCOPY:T
2.エクスプローラーの画面コピー
3.DS418Jの再起動
4.エクスプローラーの画面コピー

画面コピーを添付いたします。

ご確認いただけますと助かります。

＞ただし、作成日時がコピーされたように見えるのは、明らかなバグなので、この事はSynologyにバグとして認識してもらわなければならないですよね。
ありがとうございます。うまくSynologyに伝わればよいのですが・・・。当方だけではなんともならないような気も・・・。

よろしくお願いいたします。

書込番号：23041269

[とにかく暇な人]

＞今日は寒い。さん
ご報告ありがとうございました。
DiskStation DS418j側のバグであろうという事ははっきりしたと思いますが、Sambaのバグなり仕様なので、Synologyとしてはどうする事も出来ないという可能性も有るかもしれないですね。
という事で、私としては、作成日時を頼りにした管理をやめるか、私が書込番号:23035261で提案したような方法を採用するか、作成日時をファイル名に含めるようにしたほうが良いのではないかと思いました。

書込番号：23041341

[たく0220]

＞今日は寒い。さん

確認ありがとうございます。

＞Synologyサポートには「仕様ですか？」と問い合わせましたが、ファイル作成日時はSynology側で異常は認められず、当方のPC等が原因との見解です。

Synology側はRobocopyで正常を確認してるという事ですか…
けど具体的な原因については教えてくれなかったのですね。


＞購入した当時は、異常はなかったような気もします。(今回の症状に気が付いていなかっただけ？かも。)

ファームウェア(DSM)のバージョンをその頃まで安全に戻せるのなら良いのですが
それで問題点を指摘してもSynologyのサポートが認めてくれるか不明ですね。


＞DS418Jの再起動後、作成日時がコピー元と同じファイルは、20,020個中0個で、コピー先もコピー元も同じファイル作成日時のファイルは一つもありません。

ディスクキャッシュか何かしらのキャッシュがDS418J側に残っていて、作成日時が正しく見えてるのかもしれませんね。
残念ながらこれ以上は情報を持ってませんので、同様な症状を確認しているユーザーが現れるのを待つぐらいですね。

あとは、相談してなかったら日本の代理店に相談してみるぐらいかな。

書込番号：23041413

[tanetty]

＞今日は寒い。さん

本件、すでに多大な労力・時間を費やしてらっしゃるとのこと。
心理的負担も、いかばかりのことでしょう。
心中お察しいたします。m(_ _)m

Synologyを再起動すると、ぜんぶコピー日時になっちゃうって...。
とすると、もうあきらかに悪いのはSynologyですよね。

本件、Synologyの「仕様」なのか、「不具合」なのか、不明です。
しかし、いずれにせよ原因は、Synolgy側にある。PC側にはない。
このことは、各種実験から、ほぼ確実だといえそうです。



以下、外野の戯言で恐縮ですが。

今後、今日は寒い。さんがSynologyに対して、
どういう方針でご対応なさっていくおつもりなのか、
検討するよいタイミングなのではないか、と愚考いたします。

というのは、今日は寒い。さんが
・これまで費やした労力・時間・心理的負担
・これから費やすであろう労力・時間・心理的負担
に、みあう効果が得られるのか、
どうにも先が見えない状況だからです。

一般に、ユーザ側で「あれ？」と思う症状をメーカーに問い合わせたとき、
メーカー側では、次の順に行動をとるかと思います。

＜メーカー側の行動＞
�@ 症状の再現性を認める。
�A 再現性を認めた場合、不具合か仕様か判定する。
�B 不具合の場合、原因・解決策を探る。
�C 解決策がある場合、実施するか否か検討する。
�D 解決策を実施する。

本件では現状、�@にすら到達していません。
これから仮に、今日は寒い。さんが、
さらに苦労に苦労をかさね、�@を完了させたとしても、
�Dまでの道のりは遠そうです。

という状況を踏まえたうえで…
方向性は３つあるかと。

(a) 「どうせ�Dまでは無理だし、OKだとして時間がかかりそうだ」
という見通しのもと、Synologyとのやりとりを中止するのも、アリだと思います。

(b) 「�Dまでは無理でも、せめて�@までは完了しないと気が済まない」
という方向性も、めっちゃ理解できます。

(c) 「いやいや、�Dまで、倒れるところまでいくんだ！」
これも、よーくわかります。

私だったら、どうするかなー。
なんとなくですが、(c)のような気がします。

その際には、こんな論理展開にするかと。
「こっちでこれだけ詳細かつ緻密に実験して、
　Synlogyがクロ、PCがシロである証拠を、これだけそろえました。
　PCがクロだと主張したいなら、
　Synologyがシロである証拠を、
　今度はそちら側でそろえる番でしょ？
　違いますか？」

この論理展開をする場合、「詳細かつ緻密に実験」の資料を、
ぐうの音もでないほどしっかり記載する必要がありますが。
メーカーと戦うのは、やっぱり骨が折れますね…。
とすると、(a)の方向性もあるけど、悩むー。

以上、単なる戯言で失礼いたしました。

書込番号：23043523

[今日は寒い。]

＞みなさま

たくさんのご返信ありがとうございます。

＞とにかく暇な人さん

＞DiskStation DS418j側のバグであろうという事ははっきりしたと思いますが、Sambaのバグなり仕様なので、Synologyとしてはどうする事も出来ないという可能性も有るかもしれないですね。

他のメーカーや他の機種はどうなっているのか、疑問がわくところです。NetgearのLinuxベースNASは作成日付が消えてしまったりしないのですが・・・。

＞作成日時を頼りにした管理をやめるか、私が書込番号:23035261で提案したような方法を採用するか、作成日時をファイル名に含めるようにしたほうが良いのではないかと思いました。

当方、写真やビデオなどのデータについて、ファイル作成日時を頼りにした管理をしていました。既に作成日時を消失していますので、撮影時刻などの詳細を取り戻すこともできず残念です。これからのデータについては、ご提案のありましたように管理方法を変えていく必要があるかもしれないですね。


＞たく0220さん

＞ディスクキャッシュか何かしらのキャッシュがDS418J側に残っていて、作成日時が正しく見えてるのかもしれませんね。
＞残念ながらこれ以上は情報を持ってませんので、同様な症状を確認しているユーザーが現れるのを待つぐらいですね。

たく0220さんの、「birth time を取得する」で、作成日時が正しく見えていたファイルも、コピーを実行し日時になっていましたので、キャッシュかな？と気づくことができました。いろいろとご教示いただきまして、ありがとうございます。


＞tanettyさん

途中で、このNASをゴミにしようかとも考えたり、iSCSIで接続したらなとんかなるかな？と考えたりしました。せっかく購入したものなので、NAS本来の使い方？ができれば(他のメーカーのNASができているのですから)良いのですが、果たしてメーカーがどこまで対応してくれるかは不明です。できれば直してほしいのですが・・・。直してもらえなかったら、やはりこのNASはゴミの運命か？。いろいろ考えるところです。とりあえずメーカーには、再起動で作成日時がコピー日時に戻る症状を伝えたので、どのように対応してくれるのかを待ってみたいと思います。

メーカーからの回答がありましたら、顛末として報告させていただければと思います。

よろしくお願いいたします。

書込番号：23045746

[tanetty]

今日は寒い。さん、こんばんは。

＞再起動で作成日時がコピー日時に戻る症状を伝えたので、どのように対応してくれるのかを待ってみたいと思います。
＞メーカーからの回答がありましたら、顛末として報告させていただければと思います。

ありがとうございます。m(_ _)m
本当にたいへんそうですね…。
うまいことSynlogyが対応してくれることを、心より祈っております。



＞他のメーカーや他の機種はどうなっているのか、疑問がわくところです。

以下の情報が参考になるかどうか、甚だ疑問ですが、
何かの足しに少しでもなれば…との思いから、念のため報告させていただきます。

次のとおり、コピー元・コピー先・ツール・症状いずれも異なりますが、
私も「作成日時がコピーされない」件で悩んでいたことがあります。

今日は寒い。さんは
「Windowsから」「Synologyへ」「Robocopyで」
「コピー前半のファイルの一部が、コピー後半にコピー日時に戻ってしまうことがある」
「NAS再起動で、すべてコピー日時になってしまう」

私は、
「Macから」「QNAPへ」「rsyncで」
「作成日時がコピーされない」

このとき、どうしたか？　rsyncを
「Mac標準で組み込まれているもの」から
「外部からインストールしたもの」に
変更したら、作成日時が正常にコピーされるようになりました。
(現在も無事に運用できております)

詳しくは、下記リンク・下記情報をご参照ください。

＜作成日時等を維持したまま、まとめてファイルをコピーするには？ 2019/07/02 ＞
https://bbs.kakaku.com/bbs/K0000925629/SortID=22771912/#tab

＜実験環境・実験結果の補足＞
・コピー元は、FAT32のmicroSD内にある、動画または写真のファイル群。
・当該ファイル群は、プラネックスの監視カメラがmicroSD内に作成したもの。
・当該ファイル群には作成日時が、ファイル名内にも映像内にも埋め込まれている。
・Macは、MacBook Pro 13 (2018)。
・MacOSは、2019/7/2当時の最新版。(たぶんMojave)
・NASは、QNAP TS-431P。
・QNAPのファームウェアは、2019/7/2当時の最新版。
・QNAPは、HDDx4本のRAID5。
・作成日時は、MacのFinder上から確認。
・NASを再起動しても、作成日時は変わらない。

書込番号：23045887

[今日は寒い。]

＞tanettyさん

「rsync」でご苦労なさったのですね。お疲れ様です。また、動作検証をしていただきまして、ありがとうございます。
当方は、Windows環境ですので、「rsync」をどうしたらよいか、よくわかっていません。調査してみます。

＞みなさま

当方の知人が、Synologyの「DS218+」を所有されていたので、今回の症状について、検証していただきました。
この場をお借りして、お礼致します。

その検証結果ですが「異状はなかった」とのことでした。

当方が所有するDS418Jとは、どうも中身が違うようです？。(何が違うのかはよくわかりません・・・。)


よろしくお願いいたします。

書込番号：23047234

[たく0220]

＞今日は寒い。さん

Synology以外でも同様ですが、OSの名称がDSMと同じでもモデルごとに内容や設定は異なりますので、
確認結果からだけでは、推測するのは難しいですね。

ですのでDS218+についても、mount時のオプションで"user_xattr"ついているのかと
Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。
と同じ疑問を感じます。
仮にですがDS218+でそう設定されていたとすれば、「異状はなかった」というのは当然の結果かなっと思います。

NetgearのReadyNASに関してはSSHあるのですから、mount時のオプションとか同様に確認は出来ますよね。
私の知らない方法で作成日時を変更する手段があるのかもしれませんが、
DS418Jに関しては元々出来ない設定でないかなと思います。

あとExifとか対応してるカメラで撮影されたのであれば
ファイルのプロパティで詳細タブで撮影日時とか残ってませんか？

Robocopy以外でも例えばPowershellで

cd \\192.168.1.2\Test\Test01
Get-ItemProperty 1.dat | format-list

とすれば、NAS上のファイルでも作成日時をCreationTimeとして確認できます。

Set-ItemProperty 1.dat -Name CreationTime -Value "2019/11/01 1:08"

とすれば、作成日時を変更する事が出来ます。
Robocopyが原因かの切り分けぐらいにはなるかな？

ただ、拡張属性が無効のSambaサーバーに対して実行してもエラーとか返してくれないので実行後の確認は必要と感じます
Robocopyでも同様にエラーを返さないですね…

書込番号：23047614

[今日は寒い。]

＞みなさま

たくさんのご返信ありがとうございます。

Synologyより回答があり、今回の不具合を修正してもらえることになりました。多くの修正が必要だそうで、時間がかかるよです。
いつ頃になるかは不明ですので、DS418Jを継続使用するかゴミにするかは悩むところです。

みなさまのご協力、大変ありがとうございました。
感謝いたします。

書込番号：23049178

[たく0220]

＞今日は寒い。さん

不具合と認めてくれたんですね。
よかったですね！ ^^

原因が知りたいところですが、詳細は教えてくれないのでしょうね、きっと…

書込番号：23049216

[tanetty]

＞今日は寒い。さん

＞Synologyより回答があり、今回の不具合を修正してもらえることになりました。

ぬぉおおおおおおおおおおお！！！
スゴイ！　大勝利！！　すばらしい！！
他のDS481jユーザも、ニッコリですし！！

今日は寒い。さんの努力の賜物かと。
本当にお疲れさまでした　m(_ _)m

書込番号：23049464

[tanetty]

＞今日は寒い。さん

現在の熱狂(?)・安堵に水を差すようでたいへん恐縮ですが、油断大敵です。

「メーカーあるある」として、
次のように状況が短期間で激変した経験があります。
(Synology社ではなく、QNAP社ですが)

私「こういう症状です。不具合では？ 直してください」
　↓　（画面コピーやログのやりとりなどで３週間）
QNAP「不具合です(confirmed as a bug)。直します」
　↓　（２週間後）
QNAP「仕様です(working as designed)。ごめんね」

ここ(↓)の＜これまでのまとめ＞ご参照
https://bbs.kakaku.com/bbs/K0000925629/SortID=22261119/#22371569

「やっぱ、なおすのやーめた」と
Synology社が急に言い出すことも想定して
あらかじめ理論武装などなさっておくのもアリかと。

書込番号：23049553

[今日は寒い。]

＞たく0220さん

返信ありがとうございます。

＞原因が知りたいところですが、詳細は教えてくれないのでしょうね、きっと…

残念ながら、詳細は教えてもらっておりません。


＞tanettyさん

返信ありがとうございます。

＞「やっぱ、なおすのやーめた」と
＞Synology社が急に言い出すことも想定して
＞あらかじめ理論武装などなさっておくのもアリかと

QNAPの不具合対応、拝見いたしました。お疲れ様でございます。

今回の不具合については、当方だけの問題で、Synology社からの公式発表はありませんので、「やっぱ、なおすのやーめた。」というかもしれないですね。

次期製品DS420Jというのも、どこかで見たような気もしますし、今回の不具合は直さず、次の製品に移行してしまう。という場合もありそうな気もします。移行と同時にサポート終了かもしれません。

ですので、今回の不具合について、実際に直してもらえるかどうか、気長に待つことにします。直してもらえたかどうかを、ご報告できればと思います。

とりあえず、DS418Jの中にWindows標準の仮想ファイルシステムを作成して、そこ中にデータを保存しておいて、不具合が直ったら元に戻そうかと考えています。

もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

よろしくお願いいたします。

書込番号：23052501

[Excel]

>もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

これはっすねぇ・・・おそらくムリっす。
まっ、ワタクシの知識レベルではってことっすけどね。(;^_^A

あと、やったとしてもっすね、「今後のアップデートは、ゼッタイにしない！」って覚悟がいるっすねー。
DSMの機能向上とかがあったとしても、指をくわえているってゆーことになるっす。

まぁ、そのたんびに手を入れるってことならばいーんすけどね。('ω')

書込番号：23052558

[galaxy1]

>今回の不具合を修正してもらえることになりました。多くの修正が必要だそうで

何を修正するっていう話でした？

しかし、間接的な証拠から、製品に「多くの修正」箇所があるというところまで相手方に認めさせたのですから
大きな進展だと思います。瑕疵の立証責任はこちらにあるので、知らぬ存ぜぬで押し通されるときついのはこちらなので

＞「やっぱ、なおすのやーめた。」
とならないためにも、修正点がどこにあるのか抑えれればいいんですけどね

書込番号：23053019

[galaxy1]

分かりにくかったかもしれない

ようは、結局はお金の問題なのです。日本でこの種の請求をするには、瑕疵の存在は請求側が証明しないとなりません。つまり会社としては自分たちに不利な請求をさせたくないようコアの部分は伏せる方向に動くはずです。

一方、こういうソフトウェアの話になりますと技術屋さんが担当されていたりします。技術屋さんは、自身の技術屋としてのプライドがありますので単純に、原因追及に熱心になられていたりします。

今スレ主様が、メーカの何方に問い合わせされているかにもよりますがもし技術屋さんとお話しできているのなら、うまく技術屋さんの心を擽って、それとなくメーカが握っている原因を探るというのがよいかと思います。

書込番号：23053167

[たく0220]

＞今日は寒い。さん

＞もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

私はSynologyのNASを持ってませんので安易な事はいえませんし、大変だと思いますよ。
現時点でも情報が不足しているで、出来るとも出来ないとも言えないし、
何かあっても自力で解決しないといけないのでお勧めはしない。
複数のLinuxディストリビューションや組込み系のLinuxのクセを知ってれば、可能かもしれないかな。

自己責任の改造になるので、そこにどれだけのメリット・デメリットがあるのかも考えてほしいです。


書き忘れたけどDS218+とかのPlusシリーズはフォーマットにBtrfsというファイルシステムが使えるのでその辺の違いが大きいかと思う。
Btrfsはmountオプションに"user_xattr"と同様のがデフォでついてると思うので、あとはSambaがどの様に設定されてるかぐらい。
Plusシリーズだったら大丈夫かは、実機で確認するか代理店とかに確認するのがよいかと。

今回の件はJシリーズ全般同じかもしれないし、直ったからといって失った作成日時が戻ってくるようには感じられない。
自分ならDS418Jを1台残しておいて、もう1台は買替えを検討する。
(代理店とかで言質とっといて、Amazonとか返品しやすいとこで購入し、NGだったら返品する)

Synologyのアプリに依存した運用をしているなら、Plusシリーズが大丈夫だったらPlusシリーズに買替えを検討するか
QNAP、ReadyNAS等の他機種への移行も検討すると良いかと思う。

以前書いたように撮影日時がファイルから取得できるなら、そちらで確認する運用に変えるという事で妥協するという事もありかと思う。

書込番号：23053207

[今日は寒い。]

＞Excelさん
＞たく0220さん

やはり自分で直すのは、むつかしいようですので、手を出さないことにします。ありがとうございます。


＞みなさま

今回の不具合は、DSMの次期バージョン(7.0)での対応となるようです。(来年以降？、まだまだ先？)

PlusシリーズなどのBtrfsというファイルシステムでしたら、今回の不具合が発生しないようですので、乗り換えもアリかもしれないです。が、予算の問題が大きいので、乗り換えるにしても、まだまだ先になりそうです。

当面の運用をどうするかを考えながら、しばらくSynologyの様子をみて、直してくれそうにないなら、乗り換えようかと考えています。


今回の問題に関しまして、みなさまのご協力に感謝いたします。

大変ありがとうございました。

書込番号：23058128

NASの最上位フォルダにドライブレターを割り振るには

[ぱぴんちぇり]

メディアファイルのバックアップ兼保管場所として購入しました。

アプリを使用しているために「home」「video」「photo」「music」などの複数の共有フォルダが作成されています。
それぞれに合ったファイルを整理している状況です。

そこで件名の質問についてなのですが、
「\\NAS\video\」や「\\NAS\music\」に対してドライブレターの割り当ては方々でご説明されているのですが、
「\\NAS\」としてドライブレターを割り振ることはできないのでしょうか？

例えば音楽管理アプリ（Musicbee）を使用していますが、保管フォルダを指定する際に
現在NASはネットワークに「その他のデバイス」のカテゴリとして認識されているため、
現状ではアプリ側のネットワーク検索に引っかからない状況です。
ドライブレターを「\\NAS\music\」に割り振ればその点は解決なのですが、
今後も同様の状況で「\\NAS\video\」などすべてにドライブレターを割り当てなければならないと思うと
ごちゃごちゃしてしまって億劫に思えます。

解決方法や、「それはそういうものだからしょうがない」など、
ご教示いただければ大変たすかります。よろしくおねがいします。

書込番号：22650165

[たく0220]

＞ぱぴんちぇりさん

こんばんは。

＞「\\NAS\」としてドライブレターを割り振ることはできないのでしょうか？
そういう仕様ですので出来ません、「\\NAS\」はフォルダーではなくコンピューターになるので。

エクスプローラーで左側のリストからネットワークを選択した際
コンピューターしてNASが表示されれば良いという事であれば

https://www.synology.com/ja-jp/knowledgebase/DSM/help/DSM/AdminCenter/file_service_discovery
の「お使いの Synology NAS を WS-Discovery から検出できるようにする方法：」を確認してみてください。

その後、「Function Discovery Provider Host」と「Function Discovery Resource Publication」を有効化してください。
設定方法はネットで検索すれば沢山出てくると思います。
Windows10でネットワーク上のコンピューターが表示されない場合の対処法
https://hyzstudioblog.com/technology/4450/

を参考にしてみてください。

書込番号：22650518

[Excel]

Windows10限定っすけど、もっとも単純に、簡単に、ってゆーことならっすね、
ファイルエクスプローラの「ネットワーク」ってところにあるNASを右クリックして、「スタートにピン止めする」ってすると、一発アクセスできるっす。

書込番号：22650527

[Excel]

んで、
「ネットワークにないんですぅ〜(:_;)」
ってことならばっすね、ファイルエクスプローラに、
「\\NASの名称」
「\\NASのIPアドレス」
って入れると、左のほーに出てくるようになるっすよー。(^^)/

どうでしょうか？

書込番号：22650531

[Excel]

あるいはっすね、ショートカットを作ってもいいっす。
「\\NASの名称」
「\\NASのIPアドレス」
とかで、ショートカットを作ってみるっす。

書込番号：22650546

[ありりん00615]

一番簡単なのはデフォルトのフォルダを無視して自分用のフォルダ以下にすべてのファイルを入れることです。
ビデオや写真のファイルの保管先はアプリで変更することができます。
なお、Windows10ではセキュリティ上の理由でネットワーク探索はデフォルトで無効となっています。同じ理由で共有ドライブも推奨されていません。アクセス権の設定はしっかりしておきましょう。

書込番号：22650745

[ぱぴんちぇり]

みなさま、迅速かつ的確なご返答、誠にありがとうございます。

〇ネットワークのショートカット作成について
これが一番使いやすいとは思ったのですが、
結局先述した音楽再生ソフトなどで検出できませんでした。
私の環境だけなのかもしれませんが、念のためお伝えしておきます。

〇一つのフォルダにファイルをまとめることについて
私が調べる限りではvideostationやmomentsでフォルダ指定はできないようなのですが・・・
私の調べが甘かったのかもしれません。失礼しました。

結局はありりん00615さまのご意見にある方法で、
アプリの利用をとりあえずはあきらめることにしました。
皆様ありがとうございました。

書込番号：22651568

[Excel]

ワタシか、ぱぴんちぇりさんか、どっちかになにか勘違いがあるよーな気がするっす。

例えばっすね、デスクトップにNASのIPアドレスでショートカットを作っておいて、なにかのアプリの「ファイルを開く」的なところで、そのショートカットを指定するとっすね、ショートカット先が開いてアクセスできるんすけどねぇ・・・

何か違うのかしら。(?_?)

書込番号：22651596

[ぱぴんちぇり]

＞Excelさん
私もそう思っていたのですが、フォルダしか選択できないようなのです。少なくともMusicbeeは。
そのためデスクトップなりにショートカットを置いても、フォルダ指定の際にはデスクトップは空扱いなのですね。

書込番号：22651642

[Excel]

う〜〜ん。
実際にね、「MusicBee」のどこの操作っすか？
「ライブラリに追加」では、キチンとmp3単体ファイルまで指定できたっすよ。

そもそも、やってるところが「フォルダ指定」をするだけのところってことはないっすか？

書込番号：22651672

[ありりん00615]

たく0220さんの説明にある設定を行なわないなら、Winodows10のネットワークには何も表示されません。この場合、ドライブレターを割り当てるのが一番簡単です。この際にはDSMのコントロール パネル>ファイル共有>ファイル サービス にあるSMBを有効にしておく必要があります。
あとは\\10.0.1.12の様にIPアドレスを手入力するか\\DS418Jの様に自分で設定したNAS名を手入力するしかありません。後者はSMBを有効にした場合のみ利用可能です。

書込番号：22651812

[Excel]

もしもっすね、「フォルダー指定」するところだったらっすね、「ネットワーク」のところにでてくる「NAS名称」を選択するといけるんでないかしら。

書込番号：22651819

[ぱぴんちぇり]

＞Excelさん
ここが食い違っているところでしたね、ご指摘ありがとうございます。
（本当に皆様私が操作してるところを見られているのではないかというほどですね・・・）
仰る通りです。音楽を詰め込んでいるフォルダがあるので、それをライブラリとして指定したかったのです。
フォルダ選択のネットワークでNASが表示されないのですが、それはSMBが無効設定の為でしょうか？

＞ありりん00615さん
よくわかりました。ありがとうございます。
NAS商品の掲示板とは話がずれてしまいますが、
SMB有効にしなくてもドライブレターは割り振れますよね？SMB有効のデメリットはありますか？

書込番号：22651852

[Excel]

>SMB有効にしなくてもドライブレターは割り振れますよね？

それはっすね、共有設定されているフォルダーならって条件があるっすよ。
それでは今までと一緒にしかならないっす。('◇')ゞ
「ネットワーク」ってところに表示させるためにはっすね、「SMB1.0」を有効にせねばならんす。

ただし！
「SMB1.0」を有効にするってゆーことの「セキュリティリスク」は覚悟せねばならないっす。
検索してみてくださいねー。

そのリスクを、ぱぴんちぇりさん自身の判断で、オッケーとするんであれば、それはそれでいいっす。

「やっぱり、リスクは嫌だなぁ・・」
ってことならばっすね、フォルダー名入力するところに、「\\NAS名称」って手打ちすれば、SMB1.0オフのままでもキチンと指定できるっすよー。(^^)v

書込番号：22651875

[Excel]

「\\NASのIPアドレス」でも、おんなじっす。

書込番号：22651882

[ありりん00615]

SMB1.0は旧式のNASでSMBを利用するためのもので、これを有効にしてはなりません。
Windows10はSMB v3に対応しているので、NAS側のSMBを有効にするだけでSMBが利用可能になります。
SMBの利点はNAS名で呼び出せることです。また、Synology Assistantからドライブレターを割り当てる際は、SMBの有効化が必要になります。

書込番号：22651935

[ぱぴんちぇり]

調べてもまだ理解しきれていないところはありますが、
ご忠告を鑑みて運用を考えます。

書込番号：22651992

[Excel]

えっとっすね、
ワタクシんところでは、「SMB1.0」を無効にしたまんまでも、「\\NAS名称」でのアクセスができているっす。
標準でオンになっている「SMB2.0」が対応していてくれているってことかしら。(?_?)

書込番号：22652024

[たく0220]

一応書いておくと
WS-DiscoveryはSMBの仕様とはまったく関係ありません。
OASIS標準 web serviceとかで調べてみてください。

ネットワーク プロファイルの設定を正しく設定してれば問題があるとは思っていません。
ネットワークを公衆Wi-Fiとかのパブリックスペースで使うのか
自宅等のある程度自分の管理下のネットワークかの違いで、「パブリック」にするか「プライベート」にするかです。
初期値は「パブリック」ですが、PCがどんな環境で使われてるかPC自身で判断できないから
安全な設定の「パブリック」になってるだけだと思います。

名前解決とマスターブラウザを混ぜて考えてる情報もありますが、それぞれ別です。
最近のWindows10では自動的にmDNS動いてるので、勝手に名前解決してくれてたりします。

Music Beeで「保管フォルダを指定する際」と「ネットワークドライブの割当をしたくない」との事でしたので、
とりあえず、この手段しかないかなと思ったのですがちがったのかな？

書込番号：22652117

[Excel]

＞たく0220さん

なるほどなるほど・・。
勉強になるっす。<(_ _)>

書込番号：22652213

[ありりん00615]

WS-Discovery自体は探索だけで、探索されたDiskStationへのアクセスにはSMBが利用されるということでしょうね。
なお、DiskStation側はデフォルトではSMB v3が有効になっていませんでした。「SMBサービスを有効化」チェックボックスの下にある「詳細設定」ボタンからSMB v3による高速伝送を有効にするメニューが表示されます。

書込番号：22652264

[ぱぴんちぇり]

んーごめんなさい、すぐにお返事したいのですが、
ネットワーク周りのわからない単語が多すぎて調べながらなので遅くなってしまいます。すいません。
当初の問題もですし、quickconnectが頻繁に利用できないなど、
自分のネットワーク周りの知識の無さを恥ずかしく思います。
お返事はろくにできていませんが、大変感謝していることはぜひお伝えさせてください。

書込番号：22653723

[Excel]

まずはっすね、いまのまんまで、なんにもしないで、「MusicBee」のライブラリんとこの入力で、
「\\NAS名称」あるいは「\\NASのIPアドレス」
って入れてみて、おもわく通りに指定できるかどーかをためしてみてはどーっすか？

書込番号：22653759

[たればなな]

半年遅れですが、検索で辿り着いたので、追記します。

スレ主さんと同じく「MusicBee」で、NASのフォルダを指定できずに悩みました。
いろいろ調べて試したのですが、指定の際、ネットワークにNASが現れず…
（エクスプローラーでは覗けるし、ファイルも開けるのに）

結局、「MusicBee」の設定ファイルを直接編集することで解決しました。

設定ファイルは通常、「C:\Users\ユーザー名\AppData\Roaming\MusicBee」にある、「MusicBee3Settings.ini」です。
これをテキストエディタ（メモ帳など）で開いて、<DriveMappings>を探します。（最後の方にあります）
この下に、<string>と</string>で挟んで、NASのフォルダパスを記入して保存します。

※私の場合
<DriveMappings>
<string>\\WDCLOUD\Public\Shared Music\</string>
</DriveMappings>

設定ファイルをいじるので、必ずコピーを取ってから行ってください。
（「MusicBee」のメニューから、「編集」→「設定の保存」→「設定のスナップショットを保存」でもいいです。）

NASというより「MusicBee」の話題になってしまいました。
どなたかのお役に立てばいいのですが。

書込番号：23020353

video stationで再生できないmp4動画について

[Bonnie6950024]

mp4の動画ファイルをvideo stationで再生する際に、「マイコンピューターはこのビデオフォーマットに対応していません」と表示され、再生できないファイルがあります。

全て再生できないわけでなく、一部分です。
その再生できないファイルは別のソフトウエア、たとえばGOM playerなどでは再生できます。

この問題の解決策ををgoogleで検索したのですが、なかなかこれだと思えるものが見つかりません。

どなたが、ご教示いただけるとよろこびます。

書込番号：22512422

[NoriBay]

「mp4動画」と一口に言っても、その中に格納された映像・音声情報の形式は、1種類ではありません。
https://ja.wikipedia.org/wiki/MP4#格納できるメディアの種類

そして動画再生アプリによっては、それら全ての形式には対応していないものもあります。

世の中にはMP4の中身を解析してくれるアプリがいろいろありますから、まずはお手元の「mp4動画」の中身の形式を確認しておかれることをお勧めします。

書込番号：22512529

[Excel]

「Video Station」は万能ではないっす。
Synologyサポートでも、以下のように記載されているっす。

「Synology NAS は自分の装置用にビデオをトランスコードできますか？」
https://www.synology.com/ja-jp/knowledgebase/DSM/tutorial/Multimedia/Can_my_Synology_NAS_transcode_videos_for_my_device

「DiskStation Manager　ビデオ再生」
「
Video Station を活用すると、ビデオを直感的な操作で楽しく見ることができます。ビデオを再生するためにローカル コンピュータにVLC Web Pluginをインストールすると、表示品質や変換速度を高めることができます。
」
https://www.synology.com/ja-jp/knowledgebase/DSM/help/VideoStation/videoplayback


「本体機能にはあんまし頼らずに、ダメなときは再生側でなんとかせい！」
ってことでしょうかね。!(^^)!

書込番号：22512591

[Chubou]

その再生できない mp4 ビデオファイルを、下記のようなコンバーターで一旦変換してみると、再生できるようになるかも知れません。（確実ではありませんが）
Free Audio Video Pack は様々なオーディオ・ビデオ形式から別の形式に変換するものですが、mp4 から mp4 へ（入力も出力も mp4）という形で使ってみるということです。

Free Audio Video Pack 2.20
http://www.pazera-software.com/products/free-audio-video-pack/

書込番号：22512668

[ぼんじじじ]

早速ご教示いただきありがとうござます。
時間が許す時にじっくり読んで挑戦してみます。
ありがとうございます。

書込番号：22512998　スマートフォンサイトからの書き込み

同期時に起こるエラー通知

[ケンサンダヨ]

DS418を会社内でPC3台で共有しております。
で自宅にDS115jを設置してネット越しで同期をしております。
418側にCloudStationserverをインストールし115にCloudStationshareSyncをインストールし設定を行いました。
115のフォルダ内を確認したところ同期は出来ているように見えますが、418の通知にシステムイベントに
失敗共有フォルダ同期とDS418内のファイルを追加修正したたびにエラー通知があります。

ログセンターをインストールしたところ

Shared Folder Sync failed to sync task [共有フォルダ同期] to [自宅のナス名称]. (error code: 10)

このコメントが繰り返し発しています。何が原因でしょうか？　教えて下さい。


Synology社に問い合わせしたところ下記のようなコメントが返信されましたが、よくわかりません。


**********************************************************************************************************************

Dear Customer,

Thank you for the inquiry.Please allow us to reply in English along with Google Translation as multilingual support is limited at this time.

クラウドステーションのサーバーと共有シンクは、共有フォルダの同期とは何の関係もありません。

実際にNAS上のファイルを同期させるためにどちらを使用していますか？

Shared folder syncのエラーコード10は、サービスが閉じられているか、宛先に到達できないことを示します。

コントロールパネルの共有フォルダの同期タブを確認してください。

共有フォルダ同期を使用してNAS間でデータを同期していない場合は、タスクを削除してください。

The above reply are translated by Google Translation, please kindly let us know if the message is not understandable.

The cloud station server and sharesync is nothing related with the shared folder sync.

Which one is actually using to sync files on your NAS?

The error code 10 of Shared folder sync means the service is closed or the destination cannot be reached.

Please check the shared folder sync tab in the control panel.

If you're not using shared folder sync to sync data between NAS, please delete the task.

Yours Truly,
Pancracia Wei
Technical Support

Hours of operation: 9AM-6PM, Monday-Friday, GMT+8
**********************************************************************************************************************

よろしくお願いします。

書込番号：21745481

[LsLover]

情報量が少なく、原因については分かりませんので、ご了承ください。

『The cloud station server and sharesync is nothing related with the shared folder sync.

　Which one is actually using to sync files on your NAS?』

テクニカルサポートが質問していますが、共有フォルダの同期（sharesync）は、使用していないのでしょうか?

共有フォルダの同期
https://www.synology.com/ja-jp/knowledgebase/DSM/help/DSM/AdminCenter/application_backupserv_sharedfoldersync

『115のフォルダ内を確認したところ同期は出来ているように見えますが、418の通知にシステムイベントに
　失敗共有フォルダ同期とDS418内のファイルを追加修正したたびにエラー通知があります。』
『Shared Folder Sync failed to sync task [共有フォルダ同期] to [自宅のナス名称]. (error code: 10)』

テクニカルサポートの『The error code 10 of Shared folder sync means the service is closed or the destination cannot be reached.』からすると同期はできていないように推測されますが、「115のフォルダ内を確認したところ同期は出来ているように見えます」については、同期されていることは確認できたのでしょうか?

「Cloud Station ShareSync」の[同期方向の設定]は、どのように設定されているのでしょうか?
「Cloud Station ShareSync」では、多くの注意点「注」が記載されていますが、確認は取れているのでしょうか?

折角、テクニカルサポートのチャネルがオープン出来たようなので、具体的な設定内容や詳細情報を伝えれば早期解決に繋がると思いますが...。

Cloud Station ShareSync
新しい接続の作成
ホストとクライアントの Synology NAS デバイスの間でファイルを同期するには、先に接続を作成する必要があります。
新規接続の作成方法：
Cloud Station ShareSync のユーザー インターフェイスで左下角にある [作成] アイコンをクリックすると、ウィザードが起動します。
IP アドレス（または QuickConnect ID）、ユーザー名、ホスト Synology NAS のパスワードを入力します。 ドメイン ユーザーの方は、ドメイン名/ユーザー名を使ってログインしてください。LDAP ユーザーの方は、「username@Base_DN」でログインしてください。IPv6 でもログインできます。
ホスト Synology NAS デバイスに接続できない場合、[コントロール パネル] > [ネットワーク] > [全般] の順に選択し、プロキシを有効にします。 プロキシ設定を入力して、ホスト Synology NAS デバイスに接続してください。
同期するリモートとローカルの共有フォルダを選択し、[有効にする] にチェックマークを付けます。
接続の管理
接続を作成したら、接続情報を見たり、同期タスクを変更したりすることができます。
接続を管理する：
左側のパネルの接続リストから、編集する接続を選択します。
[概要] タブで、[管理] をクリックし、以下のいずれかを行います。
・同期を一時停止： ホストとクライアントの Synology NAS デバイスの間の同期を一時停止します。
・同期を再開： ホストとクライアントの Synology NAS デバイスの間の同期を再開します。
・リンク解除： ホスト Synology NAS サーバーとの接続をキャンセルして、リストから削除します。
・接続を編集： ログイン情報を入力し、必要であれば SSL を有効にしてください。
共有フォルダの同期
同期するローカル共有フォルダは簡単に指定できます。

共有フォルダを管理し、同期する：
1.左側のパネルの接続リストから変更したい接続を選択します。
2.[共有] タブでは、ホスト サーバーの、同期できるすべての共有フォルダはここに一覧表示されます。
3.同期する共有フォルダの横にある [有効にする] チェックボックスにチェックマークを付けて、[フォルダのパスを変更] アイコンをクリックすると、ローカルの同期フォルダを選択することができます。 続いて [OK] をクリックします。
4.[保存] をクリックすると、設定が有効になります。
注：
・他のホスト Synology NAS デバイスが同期フォルダとして使用している共有フォルダを選択することはできません。
・マウント ポイントに位置するファイルおよびフォルダは、同期されません。
ファイル同期モードの設定
Cloud Station ShareSync は、異なるファイル同期モードを使用している 2 台の Synology NAS デバイスを同期します。
共有フォルダの権限を同期する
1.[共有] タブを開き、権限設定を適用したい共有フォルダの横にある詳細設定アイコンをクリックします。
2.[権限設定] を選択し、[ファイル同期モード] ドロップダウン メニューから同期先となるホスト Synology NAS にある共有フォルダのファイル タイプを選択し、[OK] をクリックします。
3.共有フォルダの横にある [有効] チェック ボックスにチェックマークを付けて、[保存] をクリックすると設定が適用されます。
同期方向の設定
1.[共有] タブを開き、権限設定を適用したい共有フォルダの横にある詳細設定アイコンをクリックします。
2.[同期方向] ドロップダウン メニューから、共有フォルダの同期方向を選択し、[OK] をクリックします。
3.共有フォルダの横にある [有効] チェック ボックスにチェックマークを付けて、[保存] をクリックすると設定が適用されます。
https://www.synology.com/ja-jp/knowledgebase/DSM/help/CloudStationClient/DScloudclient

書込番号：21749968

[ケンサンダヨ]

連絡が遅くなり申し訳ございません。
長期間体調を崩しておりました。

一つ一つ回答をしていきたいと思います。

テクニカルサポートが質問していますが、共有フォルダの同期（sharesync）は、使用していないのでしょうか?

共有フォルダの同期
https://www.synology.com/ja-jp/knowledgebase/DSM/help/DSM/AdminCenter/application_backupserv_sharedfoldersync

この件ですが、しておりません。
なぜなら、リンク先の記載項目の注意点にあるように、共有フォルダの同期は一方性の同期ソリューションであり、同期元から同期先にしかファイルを同期しません。

私が行いたいのは双方向同期ですので、この記載を確認しましたので、設定は行っていません。


----------------------------------------------------------------------------------------------------
Shared Folder Sync
共有フォルダの同期を使用すると、LAN またはインターネットを介して共有フォルダをある Synology NAS デバイス（同期元）から別の Synology NAS デバイス（同期先）へ同期することができます。

初めて同期するときには、共有フォルダの同期は選択した共有フォルダを完全に同期します。 その後は、変更したファイルだけが同期されます。 ソースから削除されたファイルは保存先からも削除されます。

注意：
共有フォルダの同期は 1 方向性の同期ソリューションであり、同期元から同期先にしかファイルを同期しません。 双方向同期ソリューションについては、Cloud Station ShareSyncをお使いください。
----------------------------------------------------------------------------------------------------


以上、よろしくお願いします。

書込番号：21989573

[LsLover]

『私が行いたいのは双方向同期ですので、この記載を確認しましたので、設定は行っていません。』

そうですか、繰り返しとなりますが、テクニカルサポートのチャネルがオープン出来たようなので、具体的な設定内容や詳細情報を伝え他方が、早期解決につながると思います。

書込番号：21990377

Nasから音源をウォークマンへ移動できません

[kosei8]

Nasで保管している音源をウォークマンで聞きたいのですが、データの移動ができません（プロパティーを含めずにコピーしますか？とエラー表示が出てしまします）。どなたか解決策をご教示頂ければ幸いです。

書込番号：21851775

[Excel]

情報が足りません。

・ウォークマンの型番は？
・DS418jとの接続方法は？
・どういった手法でコピーを行うとしているのか？
・「プロパティーを含めずにコピーしますか？」と表示が出ても、かまわず先に進めることはできませんか？

書込番号：21852949