• Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!


  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About SNS Hal

  • Rank
    Advanced Member

Profile Information

  • Gender

Recent Profile Visitors

902 profile views
  1. We aren't aware of any issues with globalSAN and macOS 10.12. Are you using the trial version of the initiator, or the licensed version? There are very few functional limitations in the trial mode, but one of these limitations is the number of allowed concurrent connections. Please see the guide in /Applications/globalSAN for more information.
  2. Project Sharing

    It's only expected that this would be prevented if the path were to change. For example, a locked file may be at /Volumes/Projects/2017/October/example.c4d. Any change to any of the parent items would affect all children, and change the path to their location. If this isn't what you're seeing, please open a support case so we can gather more information.
  3. Best Practices for End of Day

    Hi Jeffrey, Either ShareBrowser or Finder can be used to eject volumes. The best practice is to unlock the project locks from within the ShareBrowser Client or Finder before ejecting, but if all NAS shares are unmounted, the locks should also eventually expire on their own (once the EVO has determined the NAS sessions truly are closed and not just briefly interrupted).
  4. Best Practices for End of Day

    Thanks for asking. While it’s technically better to shut down workstations from a security (see this article) and energy-saving standpoint, leaving the machines running indefinitely is not expected to pose a problem with the EVO. It is best to unmount network shares when not in use (especially if using SAN volumes). Also, here’s an article that covers the best practice for EVO shutdowns. Feel free to open a support case if you have any more questions or concerns!
  5. If you've not yet done so, please open a support case for assistance with this request.
  6. Additionally, disabling SIP during installation may be an effective workaround in your case. See our updated KB article for High Sierra for more information.
  7. Thanks for the additional details. Would you mind opening a support case so we can continue investigation?
  8. Are you performing the default installation, or customizing it to exclude any components? If you'd like to open a support case, we can take a closer look at your system to see what's happening.
  9. Hi Chris, It sounds like the OS attempted a second mount of the same target without clearing the first one. The initiator isn't involved in the disk operations, but if you'd like to open a support case, we'll be happy to take a look. Also check that sleep is disabled for both the workstation and the Synology, and that the Session Type is being sent.
  10. Hi, It's part of the overall licensing model, and is checking to see if there's an updated version available. Since your initiator is already licensed, blocking this with a firewall will not affect functionality (other than getting new updates). Feel free to open a support case if you have any more questions or concerns.
  11. Hi Eric, If this is still an issue, please open a support case so we can respond directly and ensure the configuration is correct. We can connect remotely to assist if needed, and will be able to provide additional resources reserved for registered EVO customers. Thanks, Hal
  12. Faulty LD

    Hi Don, SANmp is our SAN management software. We're not sure what the hardware is, but would be happy to take a look in a remote session, if you'd like to open a support case at support.studionetworksolutions.com.
  13. It sounds like Xtarget may be a good solution if you want to share a Fibre-attached RAID over iSCSI. Contact us if you'd like more information!
  14. Hello, The initiator is strictly a connection mechanism, with no concept of the file system. The workstation operating system handles all file operations, but it does need reliable communication with the target disk. From what we've seen, the initiator maintains the connection to the storage without issue, but as noted in a previous reply, the storage system doesn't seem to support the error detection policy that is set by default in globalSAN, so this protective policy gets disabled. Error 36 is often indicative of trouble with the file system. If you're still able to read from the disk(s), backing up the data (and maintaining current backups) would be a good first step. Most storage systems (including our own!) do include the error detection policy as added protection for block level communication.
  15. Hi Alex, If a single iSCSI connection is to be used, then the machine with the connection can share the mounted volume to the other machines using AFP (or SMB). The iSCSI workstation manages the data, since SAN storage is seen as local, and then shares it as it would any other local volume it owns. There is no need for Xsan, since the other machines will not have a block level (iSCSI or FC) connection to the storage. You said there is no plan to have multiple initiators, but if you change your mind and would like the other machines to have the speed benefit of a SAN connection, then some sort of SAN management will be required; otherwise, if multiple machines concurrently connected to the same block level target, they'd each assume ownership and quickly corrupt the file system. While Xsan can be made to work with iSCSI, we do offer a much simpler alternative, SANmp (or iSANmp), which does not require a metadata network, and allows for cross-platform sharing. You can read more about iSCSI sharing here.