Files in CIFS share with identical ACLs - different permissions behaviour

[GraceCourt]

In case it's relevant, I upgraded to FreeNAS-9.2.1.7-RELEASE-x64 (fdbe9a0) a few days after installing FreeNAS-9.2.1.6-RELEASE-x64 (ddd1e39) on a new server because of bug #5054 (by the way, I found that it was possible to very quickly cure the problem of the SID being displayed as the owner - running net cache flush did the trick).

Anyway... after setting up the new server in exactly the same way (i.e. FreeNAS configuration) as three others that I have, I copied over a large number of files from one of those other servers, almost immediately noticed something rather strange about the permissions behaviour of those files... although they all had identical permissions, they fell into two distinct behavioural groups when accessed via Windows XP or Windows 7. The first is as one might expect - everything as normal. But for the second group, it's not possible to amend either the "Archive" or the "Read-only" file attributes. Everything else works - from Windows, it's possible to alter all permissions, and to change the owner.

It's driving me mad! The only clue is that, on Windows 7, for those files on which the attributes can't be changed, the UAC box pops up warning that Administrator permission is needed... before popping up an "Access is denied" error after Administrator permission is granted. And if I copy a file using ssh, the old "broken" file can be deleted and the new copy renamed to the old - the new file then "behaves itself". But as there is 5TB of data on the server, I really don't want to fix them all that way... :(

I'm guessing that this is linked to bug #5054 but can't see how as the ACLs are being handled correctly. The only clue that I can offer is that winbind_idmap.tdb contains details of an invalid user... repairing it with net idmap check -r works, but only temporarily, because after a short while the problem re-appears:

[root@freenas4] ~# net idmap check
check database: /var/db/samba4/winbindd_idmap.tdb
Invalid USER HWM 90000000: should be 1
uid hwm: 0
gid hwm: 90000003
mappings: 4
other: 3
invalid records: 0
missing links: 0
invalid links: 0
0 changes:​

Can anyone cast any light on this, or at least confirm that this is still being caused by bug #5054?

 

[anodos]

How are you copying files to your FreeNAS server?

 

[GraceCourt]

I have two NICs in the FreeNAS server, so I connected the second using a crossover Ethernet cable to another file server (an Edge utility device with a *nix OS), and mounted a CIFS share from there to the FreeNAS box. From looking at the ACLs that came over with it, Posix ACLs were supported, so I (re)set them all on the FreeNAS box to the same values, on differing occasions to different values, as part of my quest to find the problem.

These ACLs all behaved the way I expected, with the "ogw" basic permissions all following these in the way expected, and without any difficulties in setting/changing them. The CIFS share from the FreeNAS box also behaved consistently with the differing ACLs. That is, consistently apart from the behaviour described above... :(

 

[anodos]

Have you tried clicking "apply default permissions" in the share's configuration tab in the FreeNAS GUI and then setting permissions via Windows? (Note that this will nuke however you have your permissions currently set.)

 

[GraceCourt]

Yes - same behaviour. 8 out of the 993 files "behave", the rest exhibit the aberrant behaviour described above. Whatever the root of the problem, it's repeatable, consistent, and file-specific.

 

[anodos]

Sounds like you should probably make a bug report. Is your FreeNAS box an ADS member server?