NFS folder permissions for AFP

[toxyne]

I have a couple Mac computers in network
Some of them connecting to NAS with NFS for FCPX working
Other connecting with AFP for viewing video and copy some files
The problem is a folders created from NFS connected Mac's don't allow to write from AFP connected Mac's. Read-only permission
Very big problem. Is there any solutions.
Firmware of QNAP is up to date.
Thank.

P.S. Sorry for my English

[reinob]

Without having sufficient information to answer precisely, I can only tell you that mixing NFS with any other file server protocol (in your case, AFP) is a really really bad idea.

In fact, using NFS without knowing exactly WHY you need to use it is also a really really bad idea. Drop NFS.

[toxyne]

NFS needed for storing FCPX project in same folder as video.
AFP for journalist's computers to viewing video and make scripts

[schumaku]

Unless you are ready to run a major NFS administration job on the NFS clients - read use the same UID and GID on the client, force the same U**x protection masks, an force using ACL in case you have the Advance Folder Permissions in place ... stay far away from NFS. Almost _everything_ has to happen on the NFS clients - the NAS has not much control on NFS. This is not QNAP specific - this is NFS.

Why use NFS for FCPX? Use only AFP or SMB - no issues, works smooth and at the very similar performance. Life will be easy - and any kind of interoperability works with a few clicks of managing user groups (videoeditors, journalists, ...), granting the access rights to the video share folder, ... and later just add users to these groups.

Now, if APPLE does such a B.S. like _not_ supporting AFP or SMB with FCPX any more (only local or XSAN based direct attached HFS+ volumes) - please complain to the fruit breeders about this ridiculous situation. Simply not acceptable in the year 2014. Considering Apple starts to default using SMB when connecting to Apple systems with 10.9 over the network ... and certainly not NFS.

Regards,
-Kurt.

[toxyne]

Thanks for reply. I think I switch off NFS. Not big problem to store project files elswhere

[schumaku]

Can you confirm Apple FCPX does still not work with AFP or SMB?

[toxyne]

No. It is not working for storing Librarys ... only NFS or XSAN

[schumaku]

Honestly, I have no experience in OS X NFS deployments. Are the Mac managed under an LDAP or all standalone?

Let's brainstorm NFS then again later...

No. It is not working for storing Librarys ... only NFS or XSAN

Placed your complaint as a customer with Apple already?

[toxyne]

no complaint... Apple don't hear pro customers anymore(((

[doktornotor]

Reminds me why I avoid Bitten Fruit Co. products... As noted by schumaku - unless you manage to maintain the UID/GID mappings via some sort of centralized LDAP directory, you'll have no end of trouble.

[tvdhoff]

I know this is a bit of an old topic, but am running into something similar.

I've recently purchased a TVS-871T for networked FCPX video-editing. I'm slowly beginning to discover that the easy solution that QNAP offers in its brochure isn't all it's said to be. I run a video production company, not an IT department and would like my products to work as advertised after reading a manual. (You can always hope, right?)

Even though you're completely right in saying that Apple is the one creating a problem (by not allowing FCPX users to work on a NAS environment, but only crazy expensive and complicated SAN solutions), QNAP offers this 'easy tool' to connect to your NAS using a special option just for FCPX (NFS for FCPX) without so much as suggesting the need for an LDAP directory or a caution to avoid mixed server protocols on different clients. In fact, in it's brochures it even shows how easy you can mix all of your devices together!

So, maybe things have changed after 2014 with this new machine and the NAS software, but the protocol itself stays the same of course. Do your words of caution still apply?
I've ran into nulled out creation dates on my files and I think I've got a few permission problems coming up already (yes, connected a NFS and an AFP machine to the same share).

What would be the safest bet? Connecting all clients (thunderbolt and ethernet) through AFP? That doesn't need any additional LDAP services and the like?
If changing the workflow to using FCP libraries locally with external files on a NAS (or even dumping that horrid program altogether) will give me less headaches than managing UID/GID mappings and other stuff, I will!

Thanks!

[Bob Zelin]

Hi -
the TVS-871T works wonderfully right now with the NFS network protocol and the QNAP if it's setup correctly. In January 2017, QNAP will release QTS 4.3 update, and this will have the correct version of SMB (4.3.4) that
will allow the new FCP-X 10.3 to simply use SMB to write libraries from FCP-X to the QNAP shared volume that you create. So the nightmare problem will be over soon (and up to now, you can easily use NFS).

Bob Zelin

[tvdhoff]

I have used the TVS-871T with NFS for the past year with little to no trouble. With the new software and FCPX update I've now switched to using SMB instead.

This is superslow straight out of the box, because Apple wants to sign every packet that is sent using this protocol. Like single HD speed 80-90 MB/s. It's a security measure, but if you're machine is on a trusted network where this is less of a concern, you can turn it off. If you run this single line in terminal, you tell OSX to stop checking these packets which increases the speed dramatically:

Code: Select all

printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null

Now I'm running at about 550 MB/s write and 800 MB/s read speeds, still slower than NFS, but allegedly it's a better protocol to use with regards to setup, user management etc.
FCP X works fine reading and writing libraries to the NAS, so I'm a happy camper.

Only new 'nightmare' that now exists is that FCP will freeze when you try to open a library that you've created before, while it was still using NFS. (Note, I'm leaving files in place, so they are external to the library.) I'm guessing it's trying to connect through the same protocol, which I've now disabled on the NAS.
I'm gonna try to re-open it using NFS and offline the files and then try to reopen the library using SMB and relink the files through the new share.

Anybody else has experienced this problem? And found a solution maybe?

Cheers,
Tim

[OneCD]

If you run this single line in terminal, you tell OSX to stop checking these packets which increases the speed dramatically:

Code: Select all

printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null

That's an odd command string:

• it overwrites nsmb.conf with a single entry, instead of appending a new entry. This is fine if nsmb.conf is empty.
• writes to file and stdout, then hides stdout.

Try this one instead:

Code: Select all

printf "[default]\nsigning_required=no\n" | sudo tee -a /etc/nsmb.conf

Or:

Code: Select all

sudo sh -c 'printf "[default]\nsigning_required=no\n" >> /etc/nsmb.conf'

[tvdhoff]

I see, you're right. I found this on another webpage which addressed the issue I'm having. Your solution is more elegant.

Any takers on the problem I'm describing?