9.3 File Attribute Bug?

[jlpellet]

I think I've confirmed a bug in 9.3 with respect to file attributes using Win7 client. I have a FreeNAS server that hosts a directory with several spreadsheets that are modified from various local computers. I use the archive attribute to detect changes and save the new file to several backup locations. When I upgraded the server from 9.2.1.9 to 9.3 release, the batch file stopped updating the changed files. From Win7 command line or explorer, the file archive attribute did not show as set when the file was modified. I could not change the attribute from the Win7 client - got an access denied/admin permission required. The volume is owned by guest & full rights granted. I confirmed this on another 9.3 system, which had also been upgraded. I then deleted the pool & replaced the HD then created a new pool, all in 9.3. Same problem. I reverted to a clean 9.2.1.9 install, created the pool, and tried again. The file archive attribute started being updated properly & I could mod it from the Win7 client as well. Can anyone else confirm the behaviour or suggest something to try?

 

[dlavigne]

It is worth creating a bug report since if it works as expected it should be documented. Post the issue number here after creating it at bugs.freenas.org.

 

[jlpellet]

Created issue #7189.

 

[Patrick Ryan]

I have what appears to be the same issue on a FreeNAS Mini running 9.3 - files created by one user can only be accessed as readonly by other users in the same group. I tried setting the share type to Windows instead of Unix, but newly-created files still exhibit this problem. Updating to the latest available version of 9.3 does not solve the issue. Using setfacl to manually change the ACLs works, so I've implemented a really ugly workaround by running a cron job every 15 minutes, consisting of:

cd /mnt/Main && find . -exec setfacl -m group@:rwxpDdaARWcCos:------:allow {} \;​