Security Spy can't reassociate with network drives after dismount & remount
  • I use SecuritySpy with an external NAS(Synology) and have a dedicated share from it for the recordings.
    The volume is mounted as /Volumes/NAS

    Yesterday I updated my Synology and followed this procedure:
    1. Quit Security Spy
    2. Unmount all network volumes
    3. Update Synology
    4. Remount all network volumes
    5. Start Security Spy

    SecuritySpy settings for all cameras still showed that the storage location is /Volumes/NAS, however over night it recorded many GBs to my internal SSD.

    This morning I tried individually resetting the location for each camera, even though they all still said /Volumes/NAS, however SecuritySpy kept recording to my internal SSD.

    I tried quitting it and reopening it, but still records to the internal SSD.

    The ONLY way to get it to actually start recording to the NAS mount again is a complete reboot of the host computer, despite the settings always being set to record on /Volumes/NAS

    Is there anything I can do to get it to actually record to the network drive after a drive is dismounted & remounted without having to reboot the system?

    I don't know why it is so hard for it to find the network volume when it's mounted on the system with the same name.
  • Hi.
    Your issue is with the SMB incompatibility between different Mac OS and Synology.
    What OS are you running on the SS application.
    What does Synology say about 'remount' of existing connections after a power failure.
    Ideally, you are trying to work with your mac on SMB ONLY.
    Do NOT use the Synology AFP network sharing.

    If you are putting old and new oranges together, ie. Mac OS Mavericks with a 1 yr old Synology;
    Make an alias for the Synology mount point on your desktop.
    Check in your Utilities - Keychain that you do NOT have more than ONE entry for the password for the mount point.
    Check your Keychain for the My Certificates to ensure they are blue, not brown. These are the self-signed certificates that must be authenticated manually in every Mac until High Sierra after a new OS installation.
    Synology and other devices expect to find the these certificates as 'trusted' when they connect. If they don't it will send a request for a password authentication after every disconnect/sleep/power issue ect.

    Sound difficult? These are introduced as a result of security measures imposed by firmware and security updates for the last several years.
  • Hey, thanks for your reply.
    The Synology is a DS218+ running the latest OS on it(DSM 6.2.3-25426 Update 2)

    I can't find anything related to remounting in Synology settings, however the issue is not due to the network share unmounting due to a power failure. I manually unmounted it on my Mac before the NAS is rebooted to avoid a sudden dismount, then manually mount all shares again, then start SS again manually.

    Mac OS is 10.13.6 which is the newest I can run on this Mac Mini from 2011

    I have the network shares as login items and that all works fine when I reboot the computer. SecuritySpy auto launches on login as well and this all works fine.

    The issue is when I manually quit SS, then unmount the disks, then remount them, and start SS again. SS hangs on startup, looking for the drive, yet even though it's already mounted, it can't find it.

    I am using AFP rather than SMB.
    I had an older NAS with which I was using SMB but the network copy speed was extremely slow and much faster with AFP so I switched to using that.
    I bought the new Synology NAS to replace the old NAS and kept everything as AFP.

    Are you saying native AFP is worse than SMB? FWIW, with the old NAS, I had the same issue with SMB shares where SS wouldn't be able to realize that the share was mounted without a full reboot.

    I don't have any other applications that have this issue. For example, Time Machine backup works fine and I have it backing up to another share on the same NAS which is also mounted over AFP. Somehow Time Machine/Mac OS can reassociate with the network share without rebooting but SS can't.

    So, to me, it seems like SS is not able to find the shares that are remounted manually for some reason, whereas other applications on the same computer can find the shares no problem.
  • One thing to check here is if you have set a default capture destination under Preferences -> Storage. If this was set to the old NAS that no longer exists, SecuritySpy may pause on startup (for maximum 30 seconds) looking for this drive.

    Do you think this may be the problem?
  • Hi,
    I do have the default capture destination set to the new NAS location since replacing the old one. However it doesn't pick it up upon remount.

    For my usage, it'd be great if there was a way to just stop it from recording on the internal drive if it can't find the capture location for some reason. Maybe an alert as well if that happens. At least that way it doesn't fill up the hard drive(although I do have limits set for the internal drive as well, but writing lots to it over night if I don't notice isn't ideal).
  • Try turning off AFP in the NAS, and use SMB only. This shouldn't be necessary, and this is not a problem we have seen before with either protocol, but AFP has been deprecated for some time now, and it's plausible that it may not work so well with newer macOS systems.

    After turning off AFP, mount the NAS via SMB, and then re-create the capture destination(s) in SecuritySpy (if all the cameras are recording to this NAS, simply use the default one under Preferences -> Storage, and reset all the camera-specific ones).

    In terms of failsafe recording, switching to the system drive is almost always going to be the right thing to do. Failure to record should be avoided at all costs - if some important event happens and SecuritySpy misses it due to an issue with an external drive, it would reflect badly on the software, hence why we have this mechanism in place. So, I'm not sure about adding an option to prevent this from happening. What you could do is set SecuritySpy to delete files from the system drive after a very short time (1 or 2 days), so if this does happen, space on your system drive isn't used for too long.

    In terms of a notification - SecuritySpy does log this error (you can view the log via File menu -> Open Log in SecuritySpy), and if you have entered an email address for error reports under Preferences -> General, you will be notified of this problem via email.
  • I tried your suggestion of changing to using an SMB share. It appeared to work at first however SS now records corrupted video files and doesn't work at all for any of the 4 cameras that I have.

    Usually the 4k files are 300+MB but now are recording as ~14.2MB files which don't even open.

    Going to try switching back to AFP.

    Edit: network drive ran out of space, however SS is supposed to keep 200GB free by automatically cleaning old files. This used to work, but somehow stopped working. Not sure if it's related to switching to SMB or what, but it might be why the files were corrupted.
  • A drive filling up could indeed be the cause of corrupt recordings.

    SecuritySpy should be able to automatically delete files from SMB file servers. Are you using the latest version of SecuritySpy? There were some recent fixes in terms of automatic file deletion.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!