まず考えるポイントは、Windows10とNetBSDのどちらをサーバーとして利用するかという点です。NetBSDはNFSサーバになれますが、Windows10にはNFSクライアントがありません。またWindows10はSMBで共有フォルダを作れますが、NetBSDからマウントするには多少工夫が必要です。
さらに同期させようとするファイル群を、Windows10側からNetBSDに送り付ける形にするのか、それともNetBSD側からWindows10に取りに行く形にするのかも考える必要があります。これは要するに同期処理に手作業を絡ませたくないからです。ファイルが数個程度なら、GUIツールを使って手作業で済ませることも可能でしょうけれども、場合によっては何百個もファイルがある可能性を考えると、極力手作業を排除して自動的に一連の処理が完了するようにしたいところです。
実は同期する処理は、出来ていた筈でした。NetBSD側からWindows10の共有フォルダをSMBFSとしてマウントし、別途用意される同期対象ファイルリストを基に、NetBSDからWindows10にファイルをとりに行くようにスクリプトを組んでありました。スマートではない面があるとしても、これで同期できている筈でした。ところが、何時から駄目になったのかは不明ですが、気がついたら、動かなくなっていました。
NetBSDでSMBFSをマウントするのは「mount_smbfs」と「rump_smbfs」があります。マウントされているファイルの文字コードの違いを吸収するためにrump_smbfsを利用していましたが、以下のようなエラーが出てしまいます。
[ 6.1700090] panic: no such socketもうひとつのmount_smbfsでは、メッセージが違いますが、やはりエラーになります。
[ 6.1700090] rump kernel halting...
halted
rump_smbfs: puffs_daemon got 0 bytes
mount_smbfs: unable to open connection: syserr = Connection reset by peer何が悪いのかメッセージから読み取れません。もし接続時の認証に失敗しているのであれば、そのようなメッセージが出るので、認証絡みではない気がします。
mount_smbfs: lookup 54: Connection reset by peer
この問題を解決したいと思っていますが、同期方式を再検討する必要がありそうです。
0 件のコメント:
コメントを投稿