Sorry for the silly question, but what are the next steps once 11.3-U2 is available? Should I return to the original boot environment that was cloned and update it from there?If you feel enterprising, you can extract the attached zipped file, clone your boot environment, and replace /usr/local/lib/shared-modules/vfs/zfsacl.so with it. Once you do this run the command "service smbd onerestart".
Update to 11.3-U2 and don't worry about the issue any more.Sorry for the silly question, but what are the next steps once 11.3-U2 is available? Should I return to the original boot environment that was cloned and update it from there?
Indeed. I really can't understand the logic of removing a workaround which was well established and working properly before a fix for the underlying issue was in place. I'm also annoyed to see there's still no mention of what I'd consider to be a severe problem with a core functionality of FreeNAS in the release notes for 11.3-U1. How many more people are going to run into this issue?I'm glad you've diagnosed the issue, but how is it you KNOW you've got something broken, you KNOW it worked in a previous release, and you haven't pulled the update? I'm an old-hat admin but new to FreeNAS, I assumed the stable release channel was ... stable. Is this normal? Stable update breaks expected behaviour, leave broken update in the pipe, just fix it in the next release?
Indeed. I really can't understand the logic of removing a workaround which was well established and working properly before a fix for the underlying issue was in place. I'm also annoyed to see there's still no mention of what I'd consider to be a severe problem with a core functionality of FreeNAS in the release notes for 11.3-U1. How many more people are going to run into this issue?
Update to 11.3-U2 and don't worry about the issue any more.
If possible, just revert back to 11.3.release version and wait for 11.3.U2. That's what I did.Cloned boot environment, copied the patched zfsacl.so, fixed ownership, restarted smbd and set the SMB share settings as epr above but I'm still getting incorrect destination modified timestamps after robocopy backup. This issue has ruined all of our daily backups.
If possible, just revert back to 11.3.release version and wait for 11.3.U2. That's what I did.
That's a different, but related, issue. See this post for a bit more info. The current issue (SMB copies having their last modified/created dates overwritten with the copy date/time) was introduced in 11.3-U1, and is apparently going to be fixed in 11.3-U2. In the meantime, there's a patch you can apply in 11.3-U1 here (which also requires you to follow the advice in this post), or you can revert back to 11.3-RELEASE until 11.3-U2 comes out. It's all very messy.This Jira ticket (I think this is the correct issue) says that the fix version was 11.3-U1
That's a different, but related, issue. See this post for a bit more info. The current issue (SMB copies having their last modified/created dates overwritten with the copy date/time) was introduced in 11.3-U1, and is apparently going to be fixed in 11.3-U2. In the meantime, there's a patch you can apply in 11.3-U1 here (which also requires you to follow the advice in this post), or you can revert back to 11.3-RELEASE until 11.3-U2 comes out. It's all very messy.