Mounting network shares with autofs (alternative to fstab)

[shamael]

Set the SMB version too, it helped for me. Considering the share is made with SMB version 3:

• on RPI with OSMC “-fstype=cifs,rw,vers=3.11”
• on Vero4K+ last update “-fstype=cifs,rw,vers=3.0”
  (3.11 is not working on vero4k, SMB client version I guess)

You can try the debug way too, it’s described in the wiki if I’m not wrong. You need 2 ssh sessions, the first starting “sudo automount -f -v -d” and the second to restart the systemD unit (autofs) or simply touching the share

[hdmkv]

Thanks, but doesn’t work. Tried NFS as well. Must be something I’m missing w/my QNAP. Using direct NFS adding share instead via Vero.

[JimKnopf]

@hdmkv

Using direct NFS adding share instead via Vero.

So, you haven’t tried the troubleshooting step " Testing the config:" in the article I mentioned above?

[hdmkv]

I did, thanks. Think I got it to work w/NFS:

osmc@osmc:~$ ls -lah /mnt/192.168.68.3
total 8.0K
drwxr-xr-x 3 root root 4.0K Dec 30 15:17 .
drwxr-xr-x 4 root root 4.0K Dec 30 10:53 ..
drwxr-xr-x 2 root root    0 Jan  3 12:04 4Kmovies

[darwindesign]

@fzinken

[EDIT 04/16/2023: This seems not be needed anymore]

- If your username or password includes a space
- While it is discourage to use spaces in either username or password and we urge you to change it. You could try one of these two methods to escape the space in it:
-
-   username="FIRST SECOND" or username=First\ Second

This seems unclear to me. Perhaps just state that if putting the credentials inline with a space then it must be quoted to encapsulate the space…
/mnt/<server1>/<share1> -fstype=cifs,rw,username="First Second",password=<password>,iocharset=utf8,uid=osmc,gid=osmc ://<IP of server1>/<share1>

And if using a credentials file then just use the space with no accommodation.

username=First Second
password=<password>

Either way escape characters do not work in these files either by using a "\ " or "\040".

It may also be helpful to mention that the credentials in a credentials file are read from the “=” to <LF> so any trailing spaces or <CR> will break things.

[fzinken]

@darwindesign

his seems unclear to me. P

Please feel free to correct it

[karl]

Hi,
Thanks for this great guide! I think you should update it with vers=3.1.1 to be compatible with DSM Synology smb shares or at least mention it.

[darwindesign]

@karl

you should update it with vers=3.1.1

Can you elaborate here a bit. I remember someone posting something a while back about wanting something greater than SMB v3.0 but they found that one version worked but not another, or maybe one needed a newer OSMC version or something. Does using SMB v3.1.1 work in current stable with both Synology and Windows?

[karl]

Sure, this i my setup.
I’m running the latest OSMC at a RP3.
The NAS is a old Synology running DSM 6.2.4.

First I configured the shares (/etc/auto.smb.shares) whitout any “vers” parameter. Then it mounted the shares using smb1. Then I tried vers=3 and it did not work at all.
Then after some reading I tried vers=3.1.1 and it worked.

[darwindesign]

@karl

Then I tried vers=3 and it did not work at all

You tried vers=3 and not vers=3.0 as stated in the guide?

[karl]

oops sorry, if it says 3.0 in the guide that is what I used.

[darwindesign]

@karl

I think you should update it with vers=3.1.1 to be compatible with DSM Synology

I’ve done this but the issue you had may not exist anymore with the newest updates. At least if I understand what I’ve read in this thread correctly…

Backported cifs.ko fails / Better SMB support

Hi, since the Vero 4k is still using 4.9 it exists in this weird in between state that it supports SMB 3.0 but not with encryption. This usually leads to it being rejected form Windows Servers with SMB ecryption (for other devices) and having to fallback to SMB 2.1 Additionally I really would like to use enryption Since the nice folks at Samba provide backports for the 4.9 Kernel I tried compiling my own cifs.ko I installed vero364-headers-4.9.113-60-osmc and aarch64-toolchain-osmc a…

[grahamh]

Every time I reimage a box, I install autofs then copy /etc/auto* from a backup of the old image. Today I took the trouble to diff the installed conf files (version 5.1.7-1) with my 3-4 year old conf files and it seems the preferred way of writing them has changed. Does this guide need updating? here’s a diff of auto.master - I don’t know what’s meant by a map.

osmc@osmc:~/autofs$ diff -u auto.master /etc/auto.master
--- auto.master 2023-04-19 09:00:34.156239567 +0000
+++ /etc/auto.master    2021-02-04 12:36:20.000000000 +0000
@@ -13,10 +13,20 @@
 #/net  -hosts
 #
 # Include /etc/auto.master.d/*.autofs
-# The included files must conform to the format of this file.
+# To add an extra map using this mechanism you will need to add
+# two configuration items - one /etc/auto.master.d/extra.autofs file
+# (using the same line format as the auto.master file)
+# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS map)
+# that is referred to by the extra.autofs file.
 #
 +dir:/etc/auto.master.d
 #
+# If you have fedfs set up and the related binaries, either
+# built as part of autofs or installed from another package,
+# uncomment this line to use the fedfs program map to access
+# your fedfs mounts.
+#/nfs4  /usr/sbin/fedfs-map-nfs4 nobind
+#
 # Include central master map if it can be found using
 # nsswitch sources.
 #
@@ -26,6 +36,3 @@
 # precedence.
 #
 +auto.master
-/- /etc/auto.nfs.shares --timeout 30 browse
-/- /etc/auto.smb.shares --timeout 30 browse
-

[JimKnopf]

https://manpages.ubuntu.com/manpages/focal/en/man5/auto.master.5.html]:
... To avoid making edits to /etc/auto.master, /etc/auto.master.d may be used. Files in that directory must have a ".autofs" suffix, e.g. /etc/auto.master.d/extra.autofs. Such files contain lines ....

Sounds to me like you can do it that way but don’t have to do it