Red Hat Bugzilla – Bug 244588
Export directory with spaces in the name causes problems
Last modified: 2007-11-30 17:12:07 EST
Description of problem: Last day I was exporting, using NFS, the DVD of Fedora 7, which is located usually as "/media/Fedora 7 x86_64 DVD". The export was successful, I could mount remotely the directory using the standard mount procedure, that is: mount "server:/media/Fedora 7 x86_64 DVD" /mnt The /etc/exports had the export name also between "", something like: "/media/Fedora 7 x86_64 DVD" 192.168.0.3(ro,sync) Problem was with automount, it reported an error like "cannot find location" (or similar, I do not have the logs here). Nevertheless, starting /etc/auto.net manually, it was clear that the script cut the directory name at the first space. The output was something like: -fstype... Fedora ... server:/Fedora \ ... Which, of course, is nonsense. Version-Release number of selected component (if applicable): 5.0.1-9 How reproducible: Always Steps to Reproduce: 1. Create a directory with spaces in the name, like "my dir". 2. Export with NFS. 3. Try to automount remotely. Actual results: The client cannot mount the export. Expected results: It should be mounted, since manual mount works. Additional info: The problem seems to be, at least in part, in the fact that /etc/auto.net uses "$1" in the "awk" printing. This means that only the first string of the record is printed, which, in our case, is only a part of the exported directory. I tried to add "" and "\ ", but it didn't seem to work, maybe there is a problem also in the software part that reads the output of /etc/auto.net (or I made something wrong).
(In reply to comment #0) > Description of problem: > Last day I was exporting, using NFS, the DVD of Fedora 7, > which is located usually as "/media/Fedora 7 x86_64 DVD". > The export was successful, I could mount remotely the directory > using the standard mount procedure, that is: > > mount "server:/media/Fedora 7 x86_64 DVD" /mnt > > The /etc/exports had the export name also between "", > something like: > > "/media/Fedora 7 x86_64 DVD" 192.168.0.3(ro,sync) > > Problem was with automount, it reported an error like "cannot > find location" (or similar, I do not have the logs here). > Nevertheless, starting /etc/auto.net manually, it was clear that > the script cut the directory name at the first space. > The output was something like: > > -fstype... > Fedora ... server:/Fedora \ > ... > > Which, of course, is nonsense. Does this work if "-hosts" is used instead of "auto.net"? At some point the auto.net script won't be installed anymore so you need to migrate maps to use the hosts map instead. For example: /net -hosts instead of /net /etc/auto.net Ian
(In reply to comment #1) > Does this work if "-hosts" is used instead of "auto.net"? > At some point the auto.net script won't be installed > anymore so you need to migrate maps to use the hosts > map instead. > > For example: > > /net -hosts > > instead of > > /net /etc/auto.net > > Ian > Uhm, I'm using the system out-of-the-box, so the configuration files are the default ones. The /etc/auto.master contains: /net -hosts The /etc/auto.net is installed, as well, by default, so I assumed it is used somewhere by the automounter. If this is not the case, then the problem is somewhere else. I guess you should be able to reproduce easily, do you? piergiorgio
Well, maybe to be more clear. What I do is simply a "cd /net/server" (where "server" is the nfs server name) on the client and I get the error. To be more clear, if I remove the export (from the server) with spaces the above "cd" command works (for the other exports of the server). Also if I bind mount "/media/Fedora 7 x86_64 DVD" on something like "/media/disk" and I export this last one, the "cd" command works. Hope this help further.
autofs-5.0.1-17 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
I tested the updated and it seems to work properly, the exported "Fedora DVD" is automounted without problems. I would close the bug.
As per comment #5 this problem has been resolved.