I want to have automounter mount volumes from our Synology NAS onto mountpoints that have spaces in the folder name e.g. /video on the NAS is seen as NAS Videos on the iMac. It's a family machine and it would avoid confusing members of my family if the folders were named in this manner. I'm confident of how to configure automounter, just not the syntax to get that embedded space in the directory name within the map file. Any help would be appreciated.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Automounter: Spaces in Folder names
- Thread starter SlugBlanket
- Start date
- Sort by reaction score
Thanks,
I had tried this but it didn't work so thought perhaps I was missing something in the syntax. It created the folder name as expected but there was no data in it. When I reverted back to a single word for the folder name it contained the data I was expecting. The code I have in the map at present is:
Code:
Videos afp://192.168.0.2:/videoI had changed it to
Code:
NAS\ Videos afp://192.168.0.2:/videoI then exited the directory structure, re-initialised automounter and whilst the mountpoints and directories were as I expected the lack of data threw me so I'm back to square one atm.
The data in question is an entry in the automount master file /etc/auto_master. That file has a format documented here:
https://developer.apple.com/library...ster.5.html#//apple_ref/doc/man/5/auto_master
Under the heading Quoting, the means for quoting special characters, such as whitespace or dollar-sign, is described:
Special characters, such as white space characters, a dollar sign, or an ampersand can be quoted by
escaping them with a backslash (\); this prevents white space from being interpreted as a field separator,
prevents a dollar sign from being interpreted as the beginning of a variable name, and prevents an
ampersand from being interpreted as the key field for the entry in which it occurs. A sequence of
characters can also be quoted by enclosing it in double-quotes (").
The complete description is also available in Terminal.app, as this command-line:escaping them with a backslash (\); this prevents white space from being interpreted as a field separator,
prevents a dollar sign from being interpreted as the beginning of a variable name, and prevents an
ampersand from being interpreted as the key field for the entry in which it occurs. A sequence of
characters can also be quoted by enclosing it in double-quotes (").
Code:
man auto_masterTo the OP, I suggest posting the entire auto_master file. Or use the command:
Code:
hexdump -C /etc/auto_masterOr-use-hyphens-instead-of-spaces.
I-think-most-people-will-understand-it.
A bit of an old thread but this is still a problem even in MacOS 10.12 Sierra. The man pages clearly state that \ can be used to escape any spaces, or you could use quotes, but as many have found, this simply is NOT true as automount treats those just as normal characters which of course means it doesn't match with the actual shares and folders.
Exporting folders with spaces works perfectly and as it should, use \ before the space and the correct name is exported, but it is then IMPOSSIBLE to use that share as automount CANNOT work with the space. This is a BIG problem for me as I need to share some folder names that contain spaces and I cannot change that (unless anyone can explain how to get iTunes to use different folder names in its Media folder). This is obviously a bug in the automounter code and it's been there for years. Someone has forgotten to enable the use of those escape characters and I've no doubt it would be an easy fix. But how? Apple should get on top of this as it clearly is not doing what even their own documentation states it should do, but who do we tell to fix it? Is there another version of automounter that actually works and could be installed instead?
Right now it's a dead end. You cannot automount with anything that contains a space, either in the share name or the folder you want to mount it on. Anyone got any bright ideas?
Exporting folders with spaces works perfectly and as it should, use \ before the space and the correct name is exported, but it is then IMPOSSIBLE to use that share as automount CANNOT work with the space. This is a BIG problem for me as I need to share some folder names that contain spaces and I cannot change that (unless anyone can explain how to get iTunes to use different folder names in its Media folder). This is obviously a bug in the automounter code and it's been there for years. Someone has forgotten to enable the use of those escape characters and I've no doubt it would be an easy fix. But how? Apple should get on top of this as it clearly is not doing what even their own documentation states it should do, but who do we tell to fix it? Is there another version of automounter that actually works and could be installed instead?
Right now it's a dead end. You cannot automount with anything that contains a space, either in the share name or the folder you want to mount it on. Anyone got any bright ideas?
Please read post #7.
Summary:
1. Double quotes should work. Try it. What happens?
2. You-can-always-use-hyphens.
3. Maybe the file doesn't contain what you think it does.
Use hexdump as shown in post #7, and post the output.
I'll try to be understanding here, but what exactly is the purpose of your post?
1. I already stated that quoting does NOT work.
2. I also stated I CANNOT change the name of the folders and precisely why that is the case.
3. In this context, doesn't even make any sense.
Hexdump? Of what? As shown in my previous post? That line makes no sense whatsoever. Why even write it. In fact, why post at all?
This is a very simple problem. We all know about spaces (and other special characters) in names and that there needs to be a way to avoid the issue and in the case of this automount, the docs/man pages clearly state that \ or ".." should be used, but as I said in my post, this does NOT work. Nor does any other method I or anyone else has tried. There are many questions about this on the 'Net generally and indeed many are from those who don't understand about escaping spaces etc. But there are others, like this, where the poster (me in this case) is fully aware of what should be done to avoid the problem, but that even the developers' stated methods do not work. In these cases (possibly all MacOS) the threads simply peter out with no resolution. I wanted to take this further with a clear statement that this is actually an apparently unsolvable problem because the developers have screwed up. I don't think I could have made this any clearer.
I can confirm that the path with spaces is correctly exported and that a 'mount' command is able to do exactly what is required (by using \ to escape the space), but automount in MacOS obviously has what can only be described as a bug in that when it reads the map files, it treats \ and " as regular characters (and spaces therefore as field delimiters). They appear to have forgotten to include/enable the code that identifies these as escape/quoting characters and to then appropriately deal with what they are escaping or quoting. I believe this goes back for many years and it may indeed be the case that other distros include the same bugged automount, but right now I'm only interested in what's in MacOS.
Anyone know who developed this MacOS version of automount? FreeBSD.org claim automount was developed for them and MacOS has BSD underpinnings so it seems likely that is the origin. But Sun also claim automount is their development and I did read somewhere that MacOS uses the Sun automount, although to be honest that seems less likely. In either case, did Apple then modify it further and introduce the bug. Or do BSD and/or Solaris also have the same problem.
If anyone has a real solution or any more info on the above then please let me know.
I apologize. I didn't read your post carefully.
It meant use the hexdump line in my previous post, i.e. post #7. Here it is again:
Code:
hexdump -C /etc/auto_masterCopy and paste this command-line into a Terminal window. Then copy and paste the complete output into a post here. Please use CODE tags around the pasted output.
The reason for using hexdump is to ensure the file contains correct data. In particular, some people have unintentionally used curly quotes in a file, where only neutral quotes are valid. Examples:
https://forums.macrumors.com/threads/i-need-help-with-terminal.1994613/page-2#post-23589299
https://forums.macrumors.com/thread...wireless-network.1018725/page-2#post-20656853
https://forums.macrumors.com/thread...orking-directory.1821548/page-2#post-20608019
If the auto_master file is confirmed to be well-formed, then there may be other things to look into.
You might try making an indirect map, rather than a direct map. This assumes your auto_master file contains a direct map. That's currently a guess.
You might try making an executable map. Again, this assumes you aren't doing this now.
The info on indirect and executable maps is in the man page for auto_master.
You can prove or disprove whether automount is parsing as documented by looking in the source. Here's Apple's source for it:
https://opensource.apple.com/source/autofs/autofs-259/automountd/
Older versions of source can be obtained here:
https://opensource.apple.com/
The command-line tools and daemons will be under the macOS section, in the autofs sub-section under a particular OS version.
Have you tried symlinks?
That is, make a symlink whose name contains spaces. It links to a folder whose name contains, say, hyphens. The hyphen-named item resides in the automounted file-system.
You can test the efficacy of symlinks without using automount at all. Simply create another folder somewhere, e.g. /Users/Shared, whose name contains hyphens. Create a symlink to it. Put the symlink in iTunes' Media folder. Test iTunes.
Last edited:
Apology accepted and thanks for your comprehensive consideration of the problem. However...
I know about the curly quotes problem, but it's entered in Terminal and are normal quotes that work in all other cases. Besides which, the man page states that \ can be used and that's hard to confuse with anything else and anyway typing the same character into the exports file on the server exports the path with spaces in it perfectly. It's quite clear that automount is the problem.
There is a problem in that these utilities on different distros behave differently which means reading all the different docs is not always helpful. E.g. in some you can export a symlink, but in MacOS you cannot (tried it) and I cannot do it the other way around and rename the actual folders with _ instead of space, with symlinks to them that have the real name with the space. Well, I can do that, but as I mentioned, these are iTunes Media folders and although iTunes is happy to read 'through' a symlink, it is incapable of storing files via the symlink. So the actual folders HAVE to have the correct names with spaces - both ends, as this is sharing data between iTunes on the 2 Macs.
I tried using variables (elsewhere stated that they can be used on both sides of the map, but again, that doesn't seem to apply in MacOS), but this results in the same problem and although I can use '&' in the location in the map, it doesn't avoid the 'name with space' in the key.
Using the * wildcard might help, but same as executable maps, only possible with indirect maps which cannot be used because it covers the entire parent directory, in this case, the iTunes Media folder which cannot be entirely shared. Apart from me needing some of the subfolders to be local and not shared, there is the 'Automatically Add to iTunes' folder and I dread to think what would happen if that was shared and you started dropping media files into it. Which Mac would get them? Not important though as each Mac would HAVE to have its own local instance to use for its own purposes which means I HAVE to rely on direct mounts of each folder that needs to be shared. It would all work perfectly if it wasn't for this annoying bug in automount.
I've been round and round and through this for far too long now. My current solution is to use a mount command for the folders with spaces in their name. As I said, this works perfectly just using \ to escape the space, but it's not optimum as it means another configuration and method of executing it at startup or whenever (a PIA in MacOS if you don't use cron) and also means they are hard mounted, forever. One of the beauties of automount is each folder gets mounted as it is accessed and then unmounted when not being used. So I don't want to have to go outside that, but looks like I'll have to until/unless I can resolve the problem with automount.
I would love it if someone could supply a real solution that worked for automount in MacOS, but I've scoured much of the Internet about this problem and found no solutions, just questions.
I'll take a look at the source and see what I can find.
I'm not sure what you mean by "export a symlink". Can you describe what you're doing, in what application, and what happens?
I don't use iTunes, so I don't have experience dealing with its features or foibles. I have, however, used other apps that don't like symlinks in various capacities.
What I've done in those other cases is move the symlink so it's closer to the start of the pathname. In particular, ensure the symlink itself is not the leaf name, when that element is either a directory or a file. For example, if the app BlackKnight.app wants this directory:
/Users/moi/Library/None/ShallPass
and I make a symlink at this location:
/Users/moi/Library/None/ShallPass
that links to:
/Users/Shared/knavery/FleshWound
then BlackKnight may well object to that symlink. I usually assume this is because the app uses lstat() when it should probably be using stat(), either directly or indirectly.
The trick is to move the symlink up one level, e.g. make:
/Users/moi/Library/None
a symlink to:
/Users/Shared/knavery/MortalWound/
and then make MortalWound a directory that contains a sub-dir ShallPass. Then when LameApp checks whether /Users/moi/Library/None/ShallPass is the right type and exists, the symlink is embedded deeper in the path (at None instead of at ShallPass), and so gets resolved sooner, rather than as a leaf.
Personally, I made a directory:
/Links
which I then populate with sub-dirs and symlinks, that I can point different apps to.
This trick doesn't always work, but it's worth a shot.
You might also couple this trick with explicitly changing the iTunes Media folder, as described at:
https://support.apple.com/en-us/HT204668
The way I'd approach that is to change it using iTunes, then quit iTunes. Poke around in the iTunes preferences file, which I'm guessing is a plist, to see if it contains the newly chosen path (there are several ways of peeking into plist files, ask if you need details) If there is an overt path in the plist, then manually edit that plist item so it contains the actual desired pathname, which contains a symlink at a level before the leaf part of the name.
If it turns out to be an alias file instead of a pathname, that's harder to deal with.
Interesting ideas about symlinks in different paths. I have only tried a symlink with the required name, but sitting alongside the actual folder within the same folder/directory. I'll try something as you suggest.
By 'export a symlink' I mean, er, export a symlink. Not sure how to state that differently. On the 'server' I am exporting one of the iTunes Media folders (actually 'Home Videos') which exports fine using \ but I cannot then mount it on the client due to the space. If I create a symlink called Home_Videos and could export that, then I have something I can mount on the client. Unfortunately, although on some distros this is possible and the share would actually be of the real folder ('Home Videos' in my case) even though it's exported/shared name is Home_Videos, this does not work in MacOS (and some others). There is no other way (that I've found) to export with a different name. Some networking protocols do allow the name of the share to be specified as different from the path to the actual export, but not NFS, unless it can 'export a symlink' and for me that's not an option. There's no error, it simply stops reading the exports file at that line and exports nothing more. So you get exports of any lines up to the one that contained the symlink and no others. The man page actually states there can be no symlink in any exported path. So that's that.
I've been messing with iTunes since before Apple bought it in and renamed it iTunes and over the years I've tried almost every which way to share the media content. Mostly it doesn't work, but NFS sharing and in particular the automount capabilities have opened up a way for me to make this work, albeit somewhat incompletely until I can get over the space in the name problem. So my iTunes media in not in the default location, but in any case iTunes expects a particular structure of its data storage. All the media folders (Music, Movies, Home Videos etc) HAVE to reside in its main Media folder which HAS to exist alongside the "Album Artwork" folder (another problem name I need to effect a work around) and its actual library file i.e. database it actually uses once content has been imported. Where that all is can be specified in its Preferences or simply using an alias or symlink to point to the location and it will then follow that and set the actual path in its preferences. 2 issues here. That location is not stored in any easily accessible manner. I can access it with AppleScript, but it's not written in any prefs file. However my main gripe is that Apple have an annoying habit of treating symlinks like aliases which they are not. An alias file is a redirect, but a symlink should create a path to the target that can be used as if it was the real path. This is how it was intended in unix and even in MacOS command line that's how it works. But not the GUI which in all cases will resolve the symlink, like an alias and then use the real path. So specifying a location for the Media folder by placing a symlink or an alias in the default location means iTunes will store the path to where the actual data is located and then forget about how it got there. Except...
when it comes to writing stuff. When I had a "Home Videos" symlink to the mounted Home_Videos containing the media files, iTunes would happily read anything across that symlink, but when it wanted to write into "Home Videos" it simply will not do it. If it just wanted to move a file, there would be no warning or error but the file would simply not be moved. No idea what it would do if it wanted to create a new file though. Probably silently just not do it and leave you guessing.
I'll have a go with non leaf symlinks and see where that gets me. I think I 'could' create a hard link (with no spaces) to the directory on the server and export that. This would get around the space in the name of the export. Then I'd need to find a way to mount that on the client while maintaining full read and write access for iTunes. I don't see any hard linking of directories helping with that so it's not an actual solution.
In the meantime, would you have any idea where the file parsing routines would be? I've been going through the source code, but it's hard to find something that's not there, especially when I'm not exactly fluent in C. I think the problem is with automount, but I can't be 100% that that is the actual process reading the map files. Or is it automountd? Or autofsd? I think it's automount, but that of course includes numerous headers and my guess is that such a standardised routine would be held in a header and usable in many different executables. But which header and if as I suspect it has been missed, then I'm looking for something that's not there. I really need to find out where the actual parsing routines that correctly make use of escape characters are stored for automounts that do work and then try and find those same functions in Apple's version.
It has just occurred to me that maybe most distros do have this same problem. The automount Apple uses is surprisingly based on the Sun version and maybe they have the same issue. Most unix/linux admins messing with this sort of stuff would very likely never use names with spaces as it is known to make life complicated. Mac users of course have no such qualms and so this problem would very likely only surface as a MacOS problem. Certainly the only unresolved questions I found on the 'Net about this did relate to MacOS.
I need to be able to contact someone who has been involved in writing/compiling automount to get to the bottom of this. Any suggestions?
By 'export a symlink' I mean, er, export a symlink. Not sure how to state that differently. On the 'server' I am exporting one of the iTunes Media folders (actually 'Home Videos') which exports fine using \ but I cannot then mount it on the client due to the space. If I create a symlink called Home_Videos and could export that, then I have something I can mount on the client. Unfortunately, although on some distros this is possible and the share would actually be of the real folder ('Home Videos' in my case) even though it's exported/shared name is Home_Videos, this does not work in MacOS (and some others). There is no other way (that I've found) to export with a different name. Some networking protocols do allow the name of the share to be specified as different from the path to the actual export, but not NFS, unless it can 'export a symlink' and for me that's not an option. There's no error, it simply stops reading the exports file at that line and exports nothing more. So you get exports of any lines up to the one that contained the symlink and no others. The man page actually states there can be no symlink in any exported path. So that's that.
I've been messing with iTunes since before Apple bought it in and renamed it iTunes and over the years I've tried almost every which way to share the media content. Mostly it doesn't work, but NFS sharing and in particular the automount capabilities have opened up a way for me to make this work, albeit somewhat incompletely until I can get over the space in the name problem. So my iTunes media in not in the default location, but in any case iTunes expects a particular structure of its data storage. All the media folders (Music, Movies, Home Videos etc) HAVE to reside in its main Media folder which HAS to exist alongside the "Album Artwork" folder (another problem name I need to effect a work around) and its actual library file i.e. database it actually uses once content has been imported. Where that all is can be specified in its Preferences or simply using an alias or symlink to point to the location and it will then follow that and set the actual path in its preferences. 2 issues here. That location is not stored in any easily accessible manner. I can access it with AppleScript, but it's not written in any prefs file. However my main gripe is that Apple have an annoying habit of treating symlinks like aliases which they are not. An alias file is a redirect, but a symlink should create a path to the target that can be used as if it was the real path. This is how it was intended in unix and even in MacOS command line that's how it works. But not the GUI which in all cases will resolve the symlink, like an alias and then use the real path. So specifying a location for the Media folder by placing a symlink or an alias in the default location means iTunes will store the path to where the actual data is located and then forget about how it got there. Except...
when it comes to writing stuff. When I had a "Home Videos" symlink to the mounted Home_Videos containing the media files, iTunes would happily read anything across that symlink, but when it wanted to write into "Home Videos" it simply will not do it. If it just wanted to move a file, there would be no warning or error but the file would simply not be moved. No idea what it would do if it wanted to create a new file though. Probably silently just not do it and leave you guessing.
I'll have a go with non leaf symlinks and see where that gets me. I think I 'could' create a hard link (with no spaces) to the directory on the server and export that. This would get around the space in the name of the export. Then I'd need to find a way to mount that on the client while maintaining full read and write access for iTunes. I don't see any hard linking of directories helping with that so it's not an actual solution.
In the meantime, would you have any idea where the file parsing routines would be? I've been going through the source code, but it's hard to find something that's not there, especially when I'm not exactly fluent in C. I think the problem is with automount, but I can't be 100% that that is the actual process reading the map files. Or is it automountd? Or autofsd? I think it's automount, but that of course includes numerous headers and my guess is that such a standardised routine would be held in a header and usable in many different executables. But which header and if as I suspect it has been missed, then I'm looking for something that's not there. I really need to find out where the actual parsing routines that correctly make use of escape characters are stored for automounts that do work and then try and find those same functions in Apple's version.
It has just occurred to me that maybe most distros do have this same problem. The automount Apple uses is surprisingly based on the Sun version and maybe they have the same issue. Most unix/linux admins messing with this sort of stuff would very likely never use names with spaces as it is known to make life complicated. Mac users of course have no such qualms and so this problem would very likely only surface as a MacOS problem. Certainly the only unresolved questions I found on the 'Net about this did relate to MacOS.
I need to be able to contact someone who has been involved in writing/compiling automount to get to the bottom of this. Any suggestions?
Export using what application? Export to what: a text file, clipboard, etc.?
If I wanted to exactly duplicate what you're doing, describe the specific steps you take, in which apps, to "export a symlink".
You're using the term server without explaining exactly what it means, either in terms of hardware or protocols.
You've also put the word in "scare quotes", which conventionally signals a non-standard or unconventional or ironic meaning, so I'm even less sure what you might mean.
The man page for what? NFS? The man page on which system, the Mac or your 'server'?
I don't think you've posted yet about what this 'server' is, which protocol you're connecting to it from the Mac, etc. As a result, the context of "export" is unclear as to which machine it's referring.
Sorry, I haven't found them yet. I did a brief search through several files, but nothing obvious came up. It'd probably take me upwards of a few hours of focused searching and experimenting to find out exactly what's happening and where.
The verbose options, i.e. -v to automount, might show some useful clues, partly because they have identifiable constant strings you can search for in the source.
The entire Xcode project is downloadable from Apple's website.
If there's a makefile in there, you can build everything from the command line. If not, you'll need a compatible Xcode.
I can't think of anyone specifically. It's the kind of question that may be worth asking on Stack Exchange or Stack Overflow, where there's a much higher population of technical users to draw from.
I've been doing some more exploring on this, and came across the "nfsurl" form for the location in the map.
So I suggest trying the NFS URL format, with escaped spaces in the location name.
nfsurl nfs://nfsserver/path/to/mount
smburl smb://guest@smbserver/share
afpurl afp://;AUTH=NO%20USER%20AUTHENT@afpserver/share
The AFP URL shows the use of %20 as the escaped form for a space. The NFS URL does not show this, but it's reasonable to deduce that URLs can accommodate escaped characters.smburl smb://guest@smbserver/share
afpurl afp://;AUTH=NO%20USER%20AUTHENT@afpserver/share
So I suggest trying the NFS URL format, with escaped spaces in the location name.
Ah, good thinking. I tried using %20 in the normal location format and that didn't work, but as a URL it just might. I'll try it. However, even if that works for the remote location, it doesn't help the local end, i.e. the mountpoint which also has a space and would need solving. As far as I can tell, the resulting mounted directory ought to take on the name of the exported share, but in fact it maintains the original name of the mountpoint, so either I'm wrong or it's another MacOS specific feature. Either way, it compounds the problem.
I apologise if my setup is unclear. I thought the fact that this thread was basically about automount in OSX made it clear what process was involved on the client end and the server has to be the host that is providing the shares (whether a true server or not) which as individual directories (not complete volume, that was clear was it not) means it has to be over NFS. I also stated that iTunes is involved at both ends which pretty much confirms a Mac at both ends. Well, could be Windows I guess, but this thread is all about OSX so I didn't figure it was necessary to point that out.
All of which surely makes it abundantly clear that 'export' is the actual export command for which you create the /etc/exports file to configure what you want to export. Since we're talking about automounting NFS shares between Macs, I thought all of this was clear. Again, I apologise if it was not.
So to be absolutely clear, I have 2 Macs, one is a server (really) and also runs iTunes that can be shared to any other computer or TV as the main media source that can be played anywhere on the network (my house). The other is my main Mac that I use to control and configure the server and also add new music. The problem you may know is that iTunes doesn't play well as a server and to get around this I intend to share the relevant folders/directories on the server (which I am doing perfectly) and then automount them on the client whose iTunes will then be happily using the shared content. Which it is, apart from those folders that contain a space in their name and in which instance automount fails to do what it is supposed to and allow the use of \ to escape the space and make those names usable. There are reasons why it is impossible to share the entire directory tree, which means the individual folders need to be shared in this way. This is due to the way that iTunes works with a specific directory structure, there is no possible way to change these names and some of the folders cannot be shared. This solution would work if it wasn't for the failure of automount to do precisely what it is supposed to do.
However, most of that is relevant. The important aspects are 2 Macs, a server that NFS exports several specific folders and a client that needs to automount these shares but is unable to do so as automount is unable to deal with any share that includes a space in its path, nor can it mount any usable share on any mountpoint with a space in its path. All of which is the subject of this thread I am pursuing to try and get to the root cause of the problem and hopefully fix.
Yes I have Xcode, yes I can read C but it's hard work as I'm not a C expert, nor even particularly familiar. Also, I have no idea exactly where the errant/missing code is or should be, hence someone more familiar with C and in particular automount would have a far better chance of isolating the problem, or at least helping me to isolate it. I had already thought about placing a question on Stack Exchange and intended to do so today. I am determined to fix this or get it fixed.
[doublepost=1480933373][/doublepost]
I was really hopeful about this, but exactly as all other attempts, it fails to work.
I tried a share with no spaces and it mounts fine onto a mountpoint (with no spaces) using an NFS URL. But just change the share to one with a space and although it appears to read the map and mounts something (according to the output messages and the mountpoint folder icon) there's actually nothing there. This is exactly the same as with all other attempts to mount a share with a space.
It may help engender more ideas if you explained why it's impossible to share the entire directory tree.
The remainder of this part is based on the assumption that you want to prevent access to some media content, while preserving it for others.
The two ways I can think of to prevent access to specific content are:
1. Access permissions: either traditional Posix mode + owner + group, or the more fine-grained ACLs (man chmod).
This assumes NFS is able to enforce these permissions. I don't know; you'd have to test it.
2. Duplicate the media folder, and cull the content you want to prevent access to.
To avoid actual duplication of media files, use hard links between two directory trees. The advantage to hard-links is no data duplication. The disadvantages should be well known.
Start with the original full media folder on the server Mac, which its local iTunes can access. Next, make a duplicate media folder on the server Mac. This duplicate will become the shared media tree. Then delete the items from this duplicate tree that you don't want to be accessible to the remote client Mac. Finally, go through this culled tree and make hard-links to the originals. The culled media tree is then shared, and the original iTunes media tree is not.
It should be possible to write a script that runs on the server Mac that will make and maintain hard-links between the two trees. It might use tags to decide whether to exclude a file in the original tree from being linked to the culled tree. Or it could use some other attribute of the media file (see 'man xattr'). Or it might use a black-list in a text file, or a white-list, or something like that. Yes, this means writing a script for something that automount should do.
At some point this becomes a question of what tradeoffs you're willing to accept. Will you accept a workable solution that achieves the goal in a way other than as originally desired, or will you requre a specific solution that may not be achievable, or is only achievable with a much greater investment of resources.
Sorry it didn't work out. Other than what I outlined above, I'm out of ideas at this point.I was really hopeful about this, but exactly as all other attempts, it fails to work.
I tried a share with no spaces and it mounts fine onto a mountpoint (with no spaces) using an NFS URL. But just change the share to one with a space and although it appears to read the map and mounts something (according to the output messages and the mountpoint folder icon) there's actually nothing there. This is exactly the same as with all other attempts to mount a share with a space.
I wish you luck with your post on Stack Exchange/Overflow. If something useful comes from it, please post a link to the result on this thread.
Last edited:
The reason the whole directory shouldn't be shared (I thought I'd stated this) is because of the 'Automatically Add to iTunes' folder. This is monitored by iTunes for new files which are then grabbed and imported. Sharing this between more than a single iteration of iTunes is I suspect asking for trouble if you try to use it as intended.
Also the ultimate intention was to be able to store different media on different servers, so e.g. the Music folder would be mounted from one server and the Movies folder mounted from a different server.
However I now realise this is an impossible dream and I'm giving up on this completely as I have just discovered that iTunes is silently NOT actually updating anything in the remote shared directory. Just as with trying to use an alias, it is happy to read the file, but if you try and edit any of the metadata, it is NOT written to the actual file. I only realised this when I tried to add a new file and it did throw an error which alerted me.
So thank you for your assistance on this but I am very close to deleting everything iTunes from everywhere as I'm thoroughly disgusted with what Apple have done with it. I'm sorry if this has wasted any of your time but trust me, it has wasted far more of mine. But thank you again, I appreciate your help.
Over and out.
Also the ultimate intention was to be able to store different media on different servers, so e.g. the Music folder would be mounted from one server and the Movies folder mounted from a different server.
However I now realise this is an impossible dream and I'm giving up on this completely as I have just discovered that iTunes is silently NOT actually updating anything in the remote shared directory. Just as with trying to use an alias, it is happy to read the file, but if you try and edit any of the metadata, it is NOT written to the actual file. I only realised this when I tried to add a new file and it did throw an error which alerted me.
So thank you for your assistance on this but I am very close to deleting everything iTunes from everywhere as I'm thoroughly disgusted with what Apple have done with it. I'm sorry if this has wasted any of your time but trust me, it has wasted far more of mine. But thank you again, I appreciate your help.
Over and out.
Sorry this didn't work out for you, and I hope you find something that's closer to meeting your needs.