Will FreeNAS shut down a CIFS share?

[SilverJS]

Gents,

I strongly suspect the answer to my question is "No", and that the problem lies in my Windows boxes and not in FreeNAS, but just so I eliminate the possibility...:

Will FreeNAS somehow close down, or shut down access to, a CIFS share during periods of inactivity?

Background :

I have a system setup where I rely on my FreeNAS boxes for a couple of things that seem to need a more or less constant access to the CIFS share. Among others :

1. A shared Wallpapers directory (I visit interfacelift.com every couple of months to download the latest that I like); and

2. A Backups directory, where I store one Virtual Hard Disk per Windows machine (I have Task Scheduler run a small .txt script to mount the drive 5 minutes before the scheduled backup). Gotta do it this way cuz Home edition doesn't support network locations for backups.

Everything was working fine under Windows 7, which leads me to believe FreeNAS almost certainly isn't at fault - but, for the past couple of months, access to my VHD's has been dodgy at best, and my wallpaper is always reset when I wake my computers up. When I go to check into the Personalize menu to see where Windows gets its current wallpaper, I find that Windows is looking at a different (local, I think...? haven't found a way to check) directory than the one on the NAS.

If, on sleep activation, I had left open some directories on the shares, I get a message on wakeup that the drive letter was already being used or some such, access hasn't been restored (but it is) - anyway, the connection was closed during sleep. I've updated my NIC (RealTek - yeah, I know) drivers and turned off the power management, green ethernet, etc., etc...but I still get those issues.

Is there ANY chance FreeNAS could be contributing to this?

Cheers!

 

[Ericloewe]

No, but uptime comparable to a local disk is far from guaranteed.

Anything that needs frequent access by the OS should be local. You could just rsync the wallpapers folder to a local folder on your machines. SyncToy also works.

 

[maglin]

It's proabably NETBIOS issues. I have the same happen. Not upon wake as my PC never sleeps. I didn't use a IP address for mapping my share. I moved my desktop back to a local disk as my icons always reseting was the most frustrating. A NFS share may work out better but the extra resources it requires I would rather just keep using CIFs.

 

[anodos]

You might be able to modify the deadtime parameter on samba. But I'd probably just do a periodic one-way sync (NAS to local machine) of the wallpapers dir and keep it local. Resolution by IP address will always be more reliable. I've also seen weird behavior due to client-side NIC options (shutting down for power-saving purposes).

 

[SilverJS]

No, but uptime comparable to a local disk is far from guaranteed.

Anything that needs frequent access by the OS should be local. You could just rsync the wallpapers folder to a local folder on your machines. SyncToy also works.

Wow - I feel pretty dumb for not having thought of that. =) Good suggestion, thanks - not sure why it never occurred to me.

I know nothing about NFS shares - but, regarding IP addresses and such, the behavior I described happened both with shares that were mapped with IP addresses, and with shares that were mapped with the NETBIOS server name. (Upon investigation, I found that I had mapped my shares using both protocols...)

You might be able to modify the deadtime parameter on samba. But I'd probably just do a periodic one-way sync (NAS to local machine) of the wallpapers dir and keep it local. Resolution by IP address will always be more reliable. I've also seen weird behavior due to client-side NIC options (shutting down for power-saving purposes).

How would I go about editing the deadtime parameters?

And yeah, my first attempt was to go through the client-side options first - new drivers, disable all "green" ethernet, etc. Gotta say though, in the day or so since I've done that, things are markedly better already, but just wanted to thoroughly investigate.

EDIT : Lol - just as I sent this post, went back to my desktop to find that the wallpaper had reset. =) OK, local wallpapers and a SyncToy job it is...

 

[SilverJS]

Just thought I'd post a follow-up here, in case anybody (or myself!) ends up here via Google or some such...

As it turns out, it seems the errors I was getting had nothing to do with network access - but rather, with Windows 10's built-in Sync features! I stumbled upon something in my research that hinted at that - and, sure enough, once I shut off desktop Sync (indeed, all of the Settings syncs) across my Windows 10 devices, the problem stopped categorically.