Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Forum closed   06/30/2018

      PLEASE NOTE: This forum is closed and no longer moderated. Please visit https://www.studionetworksolutions.com/support/ for assistance with your SNS products. Follow Studio Network Solutions on Twitter. Thank you!


  • Content count

  • Joined

  • Last visited

Everything posted by SNS Hal

  1. Backup Evo

    We addressed this in a support ticket, but for others' benefit: we really don't have any specific recommendations for backup software. Any software which is capable of backing up a NAS volume should work. The procedure is simply to mount the EVO volumes on a workstation and then back up those volumes.
  2. One way it could change is if the address is assigned by the DHCP server, rather than being manually assigned. Glad you got it sorted out.
  3. Can i modify Fibre Channel Target

    As a rule, mapping, unmapping, and remapping should have no effect on the data, but we can't speak for all storage systems. On the EVO, these are non-destructive operations.
  4. You may want to try first restarting the Synology. I believe disk sleep is enabled by default for the Synology, so you may want to disable that (as well as for the workstation). Additionally, it could be that the original session hasn't closed yet, and the storage believes the initiator is still connected. If the Synology is not set to allow multiple connections (to protect the storage), it may be refusing what it sees as a second connection.
  5. We determined there was no issue with globalSAN in the original report, and were able to resolve the issue. Could you let us know specifically what the issue is with the Epica? Feel free to open a support case as well.
  6. There are a few things which could be responsible for this message, which is the result of the initiator automatically trying to restore its connection. A few possible causes: The Synology may have disk sleep enabled - this can be disabled in the DSM. If its disks are sleeping, the workstation has no way of knowing and will continually try to regain access to the LUNs. The Error Detection settings on the initiator do not match those of the target. The settings need to agree in order to be effective. If a disk is too full, this can also generate these errors. It may also help to simply reboot the storage. Feel free to open a support case if you still have trouble.
  7. What version of ctld are you using? Do you still see this issue? If so, could you open a support case and reference this forum entry, with a tcpdump attached?
  8. This was taken care of in support, but for anyone else's reference, the guide can be accessed by clicking Help in the EVO web GUI.
  9. unknown volume

    Do you have filesystem translation software in place in order for Windows to understand the HFS+ volume?
  10. If you'd like to open a support case we can gather some information specific to your environment to troubleshoot this.
  11. Hi Catalano, Please open a support case and we'll be able to assist you.
  12. We addressed this issue in the support case with a new version of globalSAN. Users encountering the "Host interface controller has encountered a fatal error" message can contact us for a beta version which should correct this. (glo-382)
  13. Hi codyn, Are you able to ping the storage from Terminal? Are you using "Portal/Group" to add your target? Try removing all targets, and then re-adding the IP using "Portal/Group". You may need to toggle one or both of the settings from "iSCSI Options..." in globalSAN. Can you verify you have a LUN0 designated on the storage? This video may help as well. If you still have trouble, feel free to open a support case.
  14. Joakim reinstalled Mavericks and reported that all was well. The ticket was closed a week later with no more trouble reported.
  15. How full are the SAN volumes? Have they been formatted within the past year? (See the SAN maintenance recommendations in the SANmp Admin User Guide) Assuming the filesystem isn't too old and there's at least 15% free space, it's possible there's some trouble with the SANmp database. When you can, have all users disconnect, and then from the SANmp Admin Administrator menu, select the affected disk(s) and choose "Reset Databases for Disk..." This will require you to re-enter all users and passwords after the reset, so you may wish to first choose the Import/Export option to create a .csv containing the user names/passwords. If the behavior persists after resetting the database, feel free to open a support ticket.
  16. Hi Zebity, I found another report of similar behavior with this target, and it was unresolved. If you'd like to open a support case we can try again.
  17. We ended the support case with NEO after they purchased the ATTO initiator and reported no further issues with the Synology. Joakim has opened a support ticket and we look forward to working with him to get to the bottom of this issue. As far as we know there are exactly two users affected by this behavior, so our hope is that this second report will give us an opportunity to find a solution. We have a lot of customers successfully using both QNAP and Synology targets, and have for years, so we're confident this is something we will be able to resolve. We'll post back here with more information as it comes to light. *edited to correct typo
  18. Lucas, those messages could have originated from any number of places, so we're not too sure what's going on. If you'd like to open a support case, email support @ studionetworksolutions.com and we can gather some logs from your workstation and see if we can pin something down.
  19. Nothing is jumping out at me, but some things to try: Reboot the storage, then make sure you can still ping it. Check that port 3260 on the storage allows incoming connections. Add your target using "Target" rather than "Portal/Group" by inputting the target iqn and IP for the LUN. Turn Error detection off in globalSAN (as a troubleshooting step) Try toggling the settings at "iSCSI Options..." in globalSAN to always send AuthMethod and/or SessionType. Try renaming the naa-formatted initiator name to an iqn-formatted name. You can type directly over the name in globalSAN. (We suggest turning CHAP off for troubleshooting as well, though you should generally be able to set it.) If you still have trouble, feel free to open a support case by emailing support @ studionetworksolutions.com.
  20. Read/Write Sync

    It turns out Spotlight was accessing the media and preventing sync. This was corrected by disallowing indexing of the SAN volumes. From the support case: One thing which often prevents sync operations (and unmounts) is Spotlight. If you've not already done so, we recommend removing all SAN volumes from Spotlight's indexing service. Mount all volumes Read/Write and then navigate to Spotlight in System Preferences and drag the volume to the Privacy tab. This will only need to be one time on one workstation (for each version of OSX - for example if you have Snow Leopard and Mountain Lion, do it on one workstation of each). We recommend removing SAN volumes from Spotlight regardless; while great for local storage, it is not designed for shared storage, which is often much larger than an OS disk and will frequently be ejected. It also provides no mechanism for controlling when the indexing service will run.
  21. I believe this is the same issue for which we received a support ticket, and the power button was located. If not, please open a case by emailing support @ studionetworksolutions.com - thanks