@ke3z... funny that you should say this because yes, I did all the FW and other updates when I went through set-up. When I clicked on "check for updated" on the Promise Utility, it did a check and came back as "all software/firmware is up to date." I even did this check again with the Pegasus tech rep on the phone.
BUT, since you mentioned it, I thought I would go in and do a check for updates just one more time and LO & Behold!, it said I had a FW update waiting! So just now did the FW update and you were right; the threshold has been changed to 122F. So I am going to cancel my tech support ticket and start the 10-hour synch task now.
Thx for the response that prompted me to check one more time...
We have a new problem only peripherally related to the Pegasus RAID: on Mac OS X Server 10.7.x, new files and folders don't inherit permissions from the parent directory. It's not specific to the Pegasus RAID, it's true of any attached storage we've tried so far. Oddly, it doesn't happen with the internal server drives.
This seems like a big honkin' bug.
Just an update. I have been experiencing frequent disconnections with my R6 caused by my 900Mhz european cell phone. The problem is easily replicable by bringing my phone close to the unit. I have tried wrapping my thunderbolt cable in tinfoil, but moving my phone close to the unit, (<1 meter), will still result in random disconnections of the unit.
I have had a support ticket on the issue with promise for 5 weeks.
Here is the last response I received:
"The issue has already been addressed to the upper management and currently we are working on this issue. I am not sure about the ETA.Once the fix has came means i will update you."
It is a copy of the response I received two weeks previously requesting an update.
The unit has been on the market for over a year now, and I begin to wonder how long a fix will take to arrive...
Also a warning to anyone plugging it into a thunderbolt display, any continuous read/write to the Pegasus raid while playing sound through the thunderbolt display speakers will cause the sound to distort and become unplayable. This has been confimed by AnandTech to be a problem confined to the Pegasus Raid, and not to other thunderbolt external HD's.
Until Promise have improved the shielding on their case, and fixed the audio corruption issue on thunderbolt displays, I can only recommend people who live in europe or other 900Mz countries, or who want to play sound through their Thunderbolt Display speakers while using an external thunderbolt raid, NOT to buy the Pegasus raid.
I will update you all on the support response when I receive it.
This mighty be related to my problem as well with using the Thunderbolt cable to connect my pre Thunderbolt 2010 27 inch iMac to my 2011 17 inch MBP.
After getting numerous screen flickers/refreshes on the external monitor, I went to test my MBP at the local Apple store and I got no refresh problems. The Apple employee there asked if I had any devices near the machine, which, I did as I develop iPhone/iPad apps.
We thought it might be the devices updating over wifi that is causing the flickers. Moved the devices away, no problems.
This is after resetting the power management system several times and still getting refresh flickers.
asasaki, that simply seems like a server issue, not a Pegasus issue. I run in to it all the time when I think that OS X Server should be as friendly as the Mac OS. It's not, it's UNIX. It's user hostile.
Making sure that the directories always get the parent's permissions is tricky under OS X Server. I think there are two ways to do it, but don't recall at the moment.
A Pegasus "should" just be a device that obeys the settings given to it ala the OS X Server.
Right, I'm not blaming the Pegasus:
> "It's not specific to the Pegasus RAID, it's true of any
> attached storage we've tried so far."
However, it does affect the Pegasus RAID, and this is something anyone considering external storage for a Lion server should be aware of. It would have affected our choice (a lot!) if we were aware of it beforehand.
I can't believe a server OS would make it out the door with this kind of bug.
Asasaki, I hate to say this, but I think it's simply the way the server works.
It's incredably lame when compared to the ease of file sharing on plain old OS X, but I just think that's how UNIX works. And Apple just chose to put a GUI in front of it.
First of all, which OS X Server are you using? I'm not touching Lion Server with a 10 foot pole after using it last summer. Right now, I am using 10.6.8, but think that they should both behave the same.
From the Server Admin for AFP, select Share Points and I think what you have to do is determine if you want POSIX permissions or ACL (Access Control List) and make sure that the permissions are propogated (down) or inherited (from above). If you do that for the group settings, (and all your new users belong to that group), then all the new folders should get the proper permissions.
I know it bites, but it's been this way forever and I always have to relearn it whenever I set up a new server.
We're using the latest version of Lion server.
It's not a question of knowing how to apply permissions or how to propogate them; we're good there. We're good right up until a user creates a new folder, which then fails to inherit permissions from the parent directory; then we're hosed.
- BUT -
We're only hosed if the share point is on an external drive, not an internal drive. And this is the key point: the OS handles propogation of permissions differently for attached vs. internal storage.
Which is just plain crazy.
Look, try it yourself. Create test share points on internal and external drives on a Lion server. Assign the same permissions to both. Create a non-admin account with read/write privileges for both share points. Use the non-admin account to create a new folder in each share point. Create a new file in each of those folders, then examine permissions for each.
There shouldn't be a difference, but there will be. And that's a big problem.
Yeah, that sounds familiar, though I'm not sure if it's a new bug or the way it's always worked.
You can set your folder's permissions to be inherited from the parent, and you can use an ACL or POSIX permissions. If you're using one and it's failing, I suggest to try the other.
Getting this working properly is NEVER fun and in certainly hope it's not a new bug.
I can't try it myself. I got burned to death on Lion and Lion Server in their 1.0 release and I don't have time to waste on getting angry at Lion again.
Yeah, that sounds super strange. it shouldn't matter as all drives are just drives in the /Volumes directory. Are they all formatted as HFS+?
> Yeah, that sounds super strange. it shouldn't matter as all drives
> are just drives in the /Volumes directory. Are they all formatted as HFS+?
Yes, that's the only formatting we use for Mac drives.
And the only discernable difference we've seen is that the drives that fail to propogate permissions are external, the drives that propogate permissions properly are internal. It happens with the Pegasus RAID and with FireWire drives. We didn't try it via USB, because why would you ever use a USB drive on a server?
The one somewhat nonstandard thing we're doing is using Active Directory for authentication. But back to that core problem: it behaves differently on internal vs. external drives, and there's no way to reasonably view that as anything other than a bug.
My own today experience in France. I am working with a 27" imac with the 3,4 Ghz i7 connected to the R6 12 Tb, and mainly edit with FCPX.
Today I left the editing room for 10 minutes. When I came back, 4 of the disks had red led. The promise utility said that the corresponding disks were dead.
I called Apple store to whom I bought the Pegasus R6. They were very kind but could not help.
Then since there is no Promise offices in France, I called the UK offices. After a while, I managed to talk to a tech who very kindly guided me through the terminal. He managed to force the drives to come back.
Now the promise utility displays them as 'forced online'.
I opened a ticket in the Promise forum and send the log report.
I don't like this at all. Anyone with similar situation.
I also confirm that everytime I happen to put my Iphone 4 less than 10 cm away from the Pegasus, it disconnects. I have to shut it down and turn it on again.
Otherwise than this event, I am very happy with the thing and wish I could buy a second unit because it is already
full with 8,7 Gb out of 10 Gb in raid 5. Anyone knows if we can full the the max and still work or if like any drive, you must keep it under 80%.
I'm having the same problem. Mine has been connected to the left port from the beginning. It will randomly disconnect. I have a 4G Verizon phone so it's not just GSM and mine R4 will disconnect even when my phone is not in the room.
I have recently added a "My Book Thunderbolt Duo" drive in the daisy chain. It never disconnects. So I don't believe it's the Mac or the Thunderbolt technology in general, but the R4 itself. I'm going to try swapping the cable, but cables are rarely the issue.
How fast are your fans typically running? I just set up a new R6, and post initial sync, the fan is running steadily at 1200rpm with the Pegasus idle. This seems high to me and is a bit noisy. The firmware and utility are fully updated. I'm not going to migrate a lot of data to the R6 until I see if this is normal, or if I need to swap the unit... Promise had me dump a terminal log and confirmed the fan was running faster than expected. I am waiting to hear back from them...