Readonly DOS-flags disappear but return after CIFS restart

[glipman]

We access our FreeNAS box from a Windows environment and would like to be able to set the 'Readonly' DOS attribute.

At first this did not work as only the (unix)owner of a file can set that flag. Often the last person to edit the file becomes the owner so other people could no longer change the flag.

To work around that we set 'force user = root' in the advanced properties of the CIFS share.
This worked perfectly for about a week. Then, without any apparent reason I noticed the readonly flag was gone from all files and trying to add the flag no longer worked (no error, just no effect).

Strange, so I stopped the CIFS service and restarted it 10 seconds later==> All the flags were back on the files they were supposed to be on.
This worked fine for a week and then it happened again: all the flags gone and restarting CIFS brought them back.

Note: We are running 8.3.0 RC1 and have not upgraded to the production version yet. I could not find any tickets related to DOS-flags.
Note: In the CIFS service both 'Support DOS File Attributes' and 'EA Support' are selected.

What can cause the (support for) the read-only flags to disappear?

 

[glipman]

Finally I can reproduce this problem. After a week it happened again and this time I checked /var/log/samba/log.smbd. Whenever the readonly flags disappear I see this error:

Code:

[2012/12/03 22:16:28.308853,  1] smbd/dosmode.c:247(get_ea_dos_attribute)
  get_ea_dos_attribute: Cannot get attribute from EA on file @GMT-2012.12.03-17.00.00/..: Error = Operation not supported

This time I remembered what I had done: right click in Windows on a folder, select 'Previous versions' and on one entry press the 'Open' button. This last action triggers the error message in the smbd.log and causes the readonly-attributes to disappear.
A restart of the CIFS brings them back, press 'Open' on a Previous versions and they disappear again.

It appears to be irrelevant that I use 'force user = root' in the advanced properties of the CIFS share. On another share this is not set and it happens too.

 

[cyberjock]

First, I have to congratulate you. You did your homework when trying to see if there were any changes between RC1 and RELEASE.

Second, just because there were no tickets doesn't mean nothing was done :(.

Don't be fooled ;) In fact, I think that the main reason why most people don't upgrade is that they look at the small list of changes, see a few things that they don't care about and then decide its not worth upgrading. In fact, TONS of stuff was upgraded between 8.0.4 and 8.2, yet alot of people haven't upgraded. For instance, I submitted a ticket to add support for the entire Highpoint 35xx RAID controllers, code and all. There's no mention in the 8.2 release notes that it was added. But its definitely there since I'm using it right now.

My advice would be to upgrade to the RELEASE and see if the issue goes away. If not, then definitely open a ticket. That's somewhat a crappy thing to happen with the attributes. The fact that you identified the exact cause amazes me though. Good job! It'll definitely help the developers find and fix the problem.

As an aside, why exactly do you care about the read-only attribute? Why not just change the permissions for the CIFS share to read only or do you need some files but not all?

 

[glipman]

The problem can also be reproduced on another machine that is at the latest FreeNAS-8.3.0-RELEASE-x64 (r12701M). Should I create a ticket at support.freenas.org?

As for why we want the read-only attribute: we use SVN for revision control of source code files and the read-only attribute is used to identify which files are 'locked'.
Whether this is a proper use of SVN is another discussion put my co-workers are used to this.

 

[cyberjock]

I'm not too familiar with the ins and outs of SVN. I'm guessing there is a designed method for tracking changes, but I can't help with that at all.

Go ahead and create the ticket at support.freenas.org. Not sure how long it will take to get implemented, or when the next version will be released. But that's the best you can do unless you have code. If you have code and you include it in the ticket you can expect a 24-48 hour turnaround from personal experience :P

 

[glipman]

Ticket created at http://support.freenas.org/ticket/1930

I do not have a developing environment for FreeNAS so I will have to wait for the developers to pick up the problem and hopefully fix it.