Unable to seet scratch disk - write protected media

Question

Unable to seet scratch disk - write protected media

I am trying to set my scratch disk to a folder that is a share on a server. I have full r/w access to this folder, but FCP is saying "Unable to set scratch disk. The selected directory is on write-protected or non-writable media." I can save files into this folder and delete them and everything. ACLs for the folder give me full control, however the POSIX permissions show that I have read only. But the ACLs should essentially override the POSIX permissions. Could FCP be seeing the POSIX permissions and not the ACL entries? Is that even possible? Server is OS X 10.4.8, client is 10.4.8, FCP is 5.1.2.

Quad G5, Mac OS X (10.4.8)

Posted on Jan 5, 2007 10:07 AM

Reply

Answer 1

tallguy

Level 4

1,415 points

Jan 5, 2007 10:59 AM in response to Brent Hilgenkamp

I don't know the answer to your server configuration issues, however I do know the disk you use for media should be locally connected either a firewire device (on it's own bus or card if you use a firewire camera) or e sata for more demanding codecs or fibrechannel scsi for HD and 10 bit 422 uncompressed. you are not going to get the bandwidth required from an ethernet connection.
The media disk also should not be on the system disk or a partion thereon.

Reply

Answer 2

Jan 5, 2007 11:36 AM in response to tallguy

It's a server issue, not an FCP issue.

If you post in the server forum and get a helpful answer, please return here and paste it in to close this thread.

bogiesan

Reply

Answer 3

Jan 5, 2007 11:59 AM in response to David Bogie Chq-1

I believe it's an FCP issue because this is the only appplication that has problems with permissions on this folder. I will post in the server forum though to see if anyone has an idea. I do realize performance is not as high as it could be if I was using a local HD, but I have been editing from the share for over a year and have no complaints. We don't use tape at all and go directly to DVD so I don't need to worry about dropping a frame or two. Is it the right way? Of course not. But it works so I'm happy.

Reply

Answer 4

Jan 5, 2007 12:24 PM in response to Brent Hilgenkamp

I have been editing from the share for over a year and have no complaints.

So what changed in your environment? If it's worked for over a year, then it doesn't sound like it's a FCP problem (unless the only change in your environment was an upgrade of FCP).

Reply

Answer 5

Jan 5, 2007 12:24 PM in response to Jeff Hubbach

Normally I don't set my scratch disk there. Wanted to keep all of the render files inside the project's folder on the share.

Reply

Answer 6

Jan 5, 2007 12:34 PM in response to Brent Hilgenkamp

The first link that comes up from a google search of the error message is this:
http://docs.info.apple.com/article.html?artnum=301197

"Avoid using an Access Control List (ACL) to restrict privileges on scratch disk folders.
If you use an ACL to designate a folder's privileges, it might not perform as expected if set as a scratch disk, or may not be configurable as a scratch disk.

Instead, for example, if you want to make a user's Capture Scratch folder readable, but not writable by other users, do so with standard UNIX file permissions, as opposed to an ACL."

Reply

Answer 7

Jan 5, 2007 12:36 PM in response to Jeff Hubbach

Interesting. Thanks for the info. Would you consider that to be an FCP issue then?

Reply

Answer 8

Jan 5, 2007 12:45 PM in response to Brent Hilgenkamp

Well, it's on an Apple article with a Final Cut Pro title.

As far as it being an "issue", the article seems pretty clear:

"If you use an ACL to designate a folder's privileges, it might not perform as expected if set as a scratch disk, or may not be configurable as a scratch disk.

Instead, for example, if you want to make a user's Capture Scratch folder readable, but not writable by other users, do so with standard UNIX file permissions, as opposed to an ACL."

So, use standard UNIX file permissions if you want to use it as a scratch disk.

Reply

Answer 9

Jan 5, 2007 1:28 PM in response to Brent Hilgenkamp

Interesting. Thanks for the info. Would you consider that to be an FCP issue then? < </div>

Clearly a server issue, you just happen to be using a server with FCP. If you weren't using the server, you wouldn't have an ACL issue.

Or, wait. If you weren't using FCP you wouldn't have an ACL issue. So it's clearly a Macintosh issue. O blame the Jobs blamers.

bogiesan

Reply

Answer 10

Jan 5, 2007 1:51 PM in response to David Bogie Chq-1

You're right. It is a Macintosh issue. I wish they would fix it. Until then I'll use my PC. So, what exactly is the problem David? How should I fix it?

Reply

Answer 11

Jan 6, 2007 9:04 AM in response to Brent Hilgenkamp

Again, from the article:

"if you want to make a user's Capture Scratch folder readable, but not writable by other users, do so with standard UNIX file permissions, as opposed to an ACL."

Powerbook 15 Al Mac OS X (10.4.8) 1.5 GB RAM

Reply

Answer 12

Jan 8, 2007 6:53 AM in response to Jeff Hubbach

Here is what I was looking for.... Credit to "slowfranklin" from the thread http://discussions.apple.com/thread.jspa?messageID=3855431#3855431

"In a strict sense this is not true: if an application starts to actually look on permissions, depending on which API calls they use, they see what they ask for. So if it asks "stat?" and just looks at uid, perms etc. the app assumes it doesn't have permissions and it won't actually give kauth kernel components the opportunity to mix basic and acl permissions together.

From my experience and digging into net traces of afp traffic and ktraces I'd even say there is a bug lingering somewhere in the afp client code that adds more salt to this issue. This bug effects Freehand MX amongst other"

Reply

Answer 13

Jan 10, 2007 6:39 AM in response to Brent Hilgenkamp

You can read more about this and how it is an FCP issue here -

http://discussions.apple.com/thread.jspa?messageID=3867546#3867546

Reply

Answer 14

Jan 10, 2007 7:31 AM in response to Brent Hilgenkamp

So voice your concern to Apple.
http://www.apple.com/feedback/

Thanks for posting back with more information.

Reply