One thing that’s been constantly bugging me, as well as my wife is the fact that in general, Samba (SMB) connectivity from our Windows 7 machines is spotty at best. In general we can connect, and transfer data to and from our ZFS file server. However at seemingly random times the transfers fail, or the shares become unavailable. This is extremely frustrating especially when doing something like streaming music.
After some digging around I found the SessTimeout variable which is described as:
Determines the duration of the secondary delay used in calculating a time-out value for outstanding operations. If the redirector does not receive a response to an outstanding operation before the resulting time-out expires, it considers the operation to have failed. The value of the SessTimeout entry can be thought of as a margin for error. If there is an unexpected delay, the redirector permits the operation this extra time to complete.
Sounds promising…. So I popped up regedit on the windows workstations and added the DWORD entry SessTimeout in:
To a value of 300. After that no more timeout issues! Whoohoo! Finally!
So yesterday the wife was complaining to me that her Adobe Lightroom installation was not working correctly.
The problem she was having had to do with importing files into Lightroom.
Basically what was going on was she would open Lightroom up, click on import, and then anything within the import window would result in lightroom crashing.
After some digging around on the intertubes I found what might be the problem. Apparently Lightroom doesn’t handle partially connected drives very well (or at all) such as phones (in her case, Samsung Galaxy Note 4).
After instructing her to disconnect her phone, poof the problem is gone!
I suspect if you’re having similar issues, be sure that all disks which present themselves to windows are fully connected and available prior to attempting to import.
Today I had the task of updating my backup system, for a long time I didn’t bother rolling backups because, well I just didn’t care. However I now wanted to set something up. I remembered long ago that I had done this before, based on the excellent, albeit dated write up from Mike Rubel. After some hacking I rewrote his script to make it a bit more useful in my environment. The script now accepts a single argument, which points to a configuration file. To download the initial version of this tool I called ‘snapshots’ click on the link below.
After successfully installing Windows 7 SP1 on my wife’s new workstation I noticed right away that the system was no longer able to access my Samba NAS. After searching around for a while and trying various tips, such as making sure the following Samba configuration values were enabled:
security = user encrypt passwords = true server signing = Auto
I was still having no luck. This was with Samba 3.6.6 and everything had worked prior to SP1 upgrade.
Looking around a bit more I discovered as of SP1, Microsoft enforces 128 bit encryption on file sharing and disables the older 40 – 56 bit encryption. This is great except it seems Samba doesn’t yet support this, at least not in the NT1 protocol mode (Which I’ve found to be the most stable).
So the fix was simple, under Advanced Sharing Settings, which is accessed from the left side panel in Network and Sharing Center you should find the option: Enable file sharing for devices that use 40- or 56-bit encryption
After changing that, I was able to once again access my Samba NAS without problems.
I guess I could have used security = ADS Samba configuration option, but I didn’t want to bother with the mess of active domain controls for a single windows box.
Another thing to look at is the LmCompatibilityLevel value in Windows registry. This key can usually be found in
If the REG_DWORD type key doesn’t exist, then you’ll need to create it with the name
Generally assigning a value of 1 is found to solve most people’s windows client issues.
Lastly, and this is critical, make sure you add the windows user to the samba user database, This can be done with the smbpasswd -a option. Neglecting to do so will cause you much frustration.
So… Unforantly for me, I had to reinstall Windows 7 on my wife’s work station. Personally I can’t stand Microsoft OS’s so this was quite the chore. To make things easier I decided to just install via USB disk (Who uses CD’s anymore??). To do this I utilized my favorite application, unetbootin.
Sadly, this didn’t work. I neglected to have unetbootin install on an NTFS based USB stick. After formating the stick to NTFS and remounting it (in read/write mode), I restarted unetbootin, this time with the installtype and targetdrive arguments:
unetbootin installtype=USB targetdrive=/dev/sdd1
Once started, I had it write out the image to the USB stick, popped it into my wifes work station and was off to the races!