Regarding CIFS directory date modified.

[xCatalystx]

Hey guys,

This is the first time i've experienced this issue when using CIFS. I use the 'date modified' field alot in windows. It would seem everytime i visit the root directory some of the sub directories change there date to the current time.
Example:
-/shareroot
---/dir1
------/dir1a
------/dir1b
---/dir2
------/dir2a
------/dir2b

In this example the directories 'dir1' and 'dir2' will randomly set the modified date to my current time. I've checked within the directories and there no changes to any of the child files/dirs. This does not seem like normal behavior? My old server which is currently still on does not exhibit this issue running samba on Ubuntu.

Freenas v9.3

root@freenas ~#testparm

[global]
dos charset = CP437
workgroup = LDAP
server string = FreeNAS Server
server role = standalone server
map to guest = Bad User
obey pam restrictions = Yes
smb passwd file = /var/etc/private/smbpasswd
private dir = /var/etc/private
max log size = 51200
server max protocol = SMB2
time server = Yes
deadtime = 15
max open files = 469883
load printers = No
printcap name = /dev/null
disable spoolss = Yes
dns proxy = No
pid directory = /var/run/samba
panic action = /usr/local/libexec/samba/samba-backtrace
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
acl allow execute always = Yes
create mask = 0666
directory mask = 0777
ea support = Yes
directory name cache size = 0
kernel change notify = No
delete veto files = Yes
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.upload_cache/.qsync/.qsync_sn/
store dos attributes = Yes
strict locking = No
dos filemode = Yes

[Data]
path = /mnt/Vault/Data
read only = No
veto files = /.snapshot/.windows/.mac/.zfs/
vfs objects = recycle, zfsacl
zfsacl:acesort = dontcare
nfs4:chown = true
nfs4:acedup = merge
nfs4:mode = special
recycle:subdir_mode = 0700
recycle:directory_mode = 0777
recycle:touch = yes
recycle:versions = yes
recycle:keeptree = yes
recycle:repository = .recycle/%U

 

[xCatalystx]

I thought it might be the Thumbs.db regenerating itself but the timestamp doesn't match.

 

[anodos]

I don't see this behavior on my servers. A few thoughts.
You could try disabling atime on the CIFS share (probably not going to help).

Or you can temporarily disable file synchronization (has a better chance of helping).

The difference between your two servers may be the 'store DOS attributes' parameter, which among other things I dimly recollect stores ctime and mtime in extended attributes to make them work in accordance with NTFS semantics.

 

[xCatalystx]

You could try disabling atime on the CIFS share (probably not going to help).

Yea tried this but it didnt help.

Or you can temporarily disable file synchronization (has a better chance of helping).

Sorry what are you referring to?

The difference between your two servers may be the 'store DOS attributes'

Im pretty sure (looking at my old conf) that I have dos attributes on.

The only other difference other than ZFS is im using windows acl's rather than unix with smb read/write lists. The weird thing is I have 4 datasets each with there own share (all windows, on the same volume, all mounted as there own network drive on each machine.) and only this one is showing these symptoms.

as a side note: geez shadow copy is much easier to configure on freenas =)

 

[anodos]

Yea tried this but it didnt help.
Sorry what are you referring to?

Code:

veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/:2e*/.@__qini/.Qsync/.upload_cache/.qsync/.qsync_sn

I assumed that the cache and .qsync folders / files you were vetoing were relating to some sort of file synchronization program. If not, then your best bet on tracking down the problem is to increase the log level of samba to "debug", reproduce the problem, then read through the admittedly massive log file (/var/log/samba4/log.smbd) to find out what is being modified / what is doing the modifying.

Do you have any mac clients connecting to the share?

 

[xCatalystx]

the veto string is a copy from my old server which fixed problems with some programs (as you have said) however none of those are using that dataset/share. currently in the last week no mac clients, but I do have a few connect several times month.

I will try upping the debug level. other than this issue my setup is pretty much ready to go completely live.

That and some weird "arp moved from" message i get each night, but from what i can tell is insignificant, though it would be nice not to get them.

 

[xCatalystx]

OK reporting back after a week of watching/test: I seem to be getting some mystery writes are occurring on the share even with no clients plugged in to the network (via wifi vpn or lan). Problem is the log is not providing me with a client id / ip. Does provide me the user, but that is not helpful as its a generic user used for a few devices (which none of them are currently connected).

 

[anodos]

OK reporting back after a week of watching/test: I seem to be getting some mystery writes are occurring on the share even with no clients plugged in to the network (via wifi vpn or lan). Problem is the log is not providing me with a client id / ip. Does provide me the user, but that is not helpful as its a generic user used for a few devices (which none of them are currently connected).

You should also look for cron jobs or jails that may be modifying the data on the share.

 

[xCatalystx]

Will investigate my jails further. On a separate note regarding cifs; not sure on how best to explain this but.... when a jail copies a file to a directory that is mounted to a freenas dataset; how long should it take for the file to appear in cifs?

example: if the mount path is /mnt/datahere and i go touch /mnt/datahere/example.log it shows up in the filesystem but you cannot see if in cifs straight away. If i than login to the cifs share and make a change to that directory, it seems to update the view as it were and now you can see the file. Usually i do not notice it because after a period of time it seems to appear, but it does seem to happen.

Or would it be better practice to mount the jail via cifs than internally using the mount page under jails?

 

[anodos]

Will investigate my jails further. On a separate note regarding cifs; not sure on how best to explain this but.... when a jail copies a file to a directory that is mounted to a freenas dataset; how long should it take for the file to appear in cifs?

example: if the mount path is /mnt/datahere and i go touch /mnt/datahere/example.log it shows up in the filesystem but you cannot see if in cifs straight away. If i than login to the cifs share and make a change to that directory, it seems to update the view as it were and now you can see the file. Usually i do not notice it because after a period of time it seems to appear, but it does seem to happen.

Or would it be better practice to mount the jail via cifs than internally using the mount page under jails?

Personally, I try only to modify CIFS shares via cifs. If you hit F5 in explorer does the file appear? By default 'kernel change notify' is set to 'no' as a workaround to a bug that affected 9.2.1.3 (I believe). This means that changes made outside cifs may not appear in cifs clients immediately without hitting F5.

 

[xCatalystx]

Personally, I try only to modify CIFS shares via cifs.

Well permissions seem to be fine seems i've set them all as inherit. Moving forwards would it be a better idea to mount the only two jails using the cifs dataset using 'mount_smbfs' rather than internally? Both jails only write new files based on a polling program (separate dataset & share to my above problem).

If you hit F5 in explorer does the file appear?

Nope. Still shows the same. Really weird. Im currently out atm, i could try again using a separate client aswell once i return.

Other than these hiccups freenas has been a pretty big improvement over the previous setup (bit of a learning curve but not much). Was hoping for better write performance, but it still really good.

 

[cyberjock]

CIFS may detect the change immediately, or it make take several minutes. CIFS expects to basically "own" the directories and files its sharing. So it doesn't expect you to suddenly add or remove directories or files.

I've never had to wait more than 5 minutes though.

Also Windows does it's own caching and such, so that can also screw you up.

Woohoo!

 

[xCatalystx]

CIFS may detect the change immediately, or it make take several minutes. CIFS expects to basically "own" the directories and files its sharing. So it doesn't expect you to suddenly add or remove directories or files.

Yea but this was working fine on my previous setup. I might try and swap the mounts to use cifs rather than direct.

Also Windows does it's own caching and such, so that can also screw you up.

Yea I took that into account. I use a file browser app that lets me clean session/result (very helpful for testing this exactly problem).

I can confirm that its not the cache on the machine. If i write a file, than open that directory on win client #1 it does show up. If i quickly start up another machine and browse to the folder (not mapped, using UNC path and being prompted for user/pass) it still doesn't show up. The moment make any change in that directory from either client (create/delete/modify a file) both machines update and the file becomes visible.

I think anodos theory maybe right on the money; that the kernel notify trigger is not being passed to smb4, which in turn is not running the internal synchronization job for the smb4.