I have two shares working with systemd.automount but adding another share fails on the client end. The fstab entries on the client machines all use the following format:
All of the shares are specified in the YaST NFS server module on the server machine and the client NFS client module. I cannot figure out why a newly added share registers an error on the client end. I must be missing something very simple.
Everything you do in /etc/exports is not imediatly active. Using exportfs propagates it to the master export table.
At boot exportfs is run. When one changes /etc/exports later during system up time, this becomes active either on next boot, or on using exportfs.
You are correct. An error message was shown in the title, but we never got explained where it was shown. I assume it was a side effect of the export not being found (as the server was not updated with the new information). But a not very clear error in any case.
As you can see from last my two posts (##2 &3), I determined the reason for the error: the new share had not been exported. Because I had been using autofs for some time, the first two shares had been exported long before I added systemd.automount entries to the fstab files on the client machines. Since the d and e shares worked, I was initially stumped - the very same fstab entry for f (and then g) failed. (Thank you, Henk, for suggesting systemd.automount in another thread; I used your formulation for the options and it works very well.)
After reading the Red Hat post and the exportfs man page, I realized that the YaST NFS server was not exporting the share. If I was creating the share via the command line, I would expect to have to use the exportfs command, perhaps with option -a. There must be a reason why the developers did not incorporate the export function into the YaST NFS server module.
The title is based upon the information I had when I first posted this thread. The phrase “unknown option” was generated in YaST when I accessed the share in YaST NFS client on a few machines and noticed an asterisk in the share point entry. (Edit > OK > "Error - Unknown option: ‘x-systemd.automount’) An asterisk and the same error message also appear when the mount times out. In retrospect, a more accurate title would be: “mount.nfs: access denied by server while mounting.” That was generated in Dolphin on the client machines when I attempted to access the share.
Thanks for the explanation. I assume that YaST gives the “umknown option” message because it does not understand the systemd options.
On the sever side, indeed we system managers learned already 40 years ago that after editing the /etc/exports, you should do exportfs to activate those changes.
And I am with you when you say that YaST > NFS Server should do the exportfs by itself after changes are done (those are the details we have system managment tools like YaST for). I do not understand why it doesn’t. Maybe someone could document that and file a bug report?
Thank you. I will take some screen shots in NFS client and post them so that you can see the exact message in context. I can then submit a bug report if you believe it would aid the developers.
Fine. Maybe better do not call them “shares”, but exports. They are NFS exports and NFS mounts. Already years before Microsoft invented it’s own terminlogy. And as the saying goes: "when doing Unix/Linux, forget everything you learned about MS Windows.
I am afraid that the mentioning of the MS term there is done because many people will know that term from their former life as MS Windows adepts. And the author wants to catch their attention.
