AutoFS issues after Bullseye upgrade

Help and Support Vero 4K / Vero 4K +
1

All my root filesystem /mnts are inaccessible (with autofs) after the upgrade. Any ideas anyone ?

2

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device twice(!)

  • reproduce the issue

  • upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

image
image960×539 41.4 KB

3

Here’s my logs:

(removed)

Also here’s a line from my auto.smb.shares file -

/mnt/nuputer10/#flacs -fstype=cifs,rw,username=Chris\ Gregory,password=*******,iocharset=utf8,uid=osmc,gid=osmc,vers=3.0 ://192.168.1.100/#flacs/

I’m guessing, but perhaps these mounts need updating in someway ?

This looks like the culprit (see below) - this error - 'invalid character “=” found in location - any idea what the correct syntax is now? No idea which instance of ‘=’ is causing the issue, as there are several.

Sep 18 22:32:27 osmc automount[2621]: validate_location: invalid character "=" found in location Gregory,password=******,iocharset=utf8,uid=osmc,gid=osmc,vers=3.0 ://192.168.1.100/#flacs/

Thinking back to previous experience, can the username/password now be set in a .smbcredentials file, as this has never worked @fzinken ? Perhaps this is the issue (assuming that the first instance of ‘=’ in the error message is the problem).

Just tried the .smbcredentials method, no luck, besides the username/password combination in the mount command should still work (although not as secure).

It really would help to kow what the expected syntax is for the /mnt commands in /etc/auto.smb.shares as read by osmc automount

4

Hi,

I’m not sure about this, but it looks to me that the newer version of autofs doesn’t the like the way the space in the username is being escaped. I use NFS rather samba but a quick Google search, came up with a couple of possible solutions. The first one is to try using the octal ASCII code for special character for space:

/mnt/nuputer10/#flacs -fstype=cifs,rw,username=Chris\040Gregory,password=*******,iocharset=utf8,uid=osmc,gid=osmc,vers=3.0 ://192.168.1.100/#flacs/

Alternativly use ~/.smbcredentials:

username="Chris Gregory"
password=<password>

Thanks Tom.

5

Thanks Tom, I’ll try those ideas, I did try the .smbcredentials but escaped the space in the username with a ‘\’, guess I could try it with double quotes.

I’ll get back to you.

Chris

1 Like
6

I now have autofs working again.
With this new version of autofs/[osmc mount] the username cannot contain spaces or any form of escape sequence using ‘\’ and octal/hex character codes. This applies both to its explicit use in ‘username=’ of the ‘/mnt command’, and also when used in a .smbcredentials file.

I am now using a username without spaces (a microsoft account name infact) specified in a .smbcredentials file, which is infact more secure (because it is no longer part of the auto.smb.shares file (which is backed-up), and can also be seen in the debug logging.

1 Like
7

This is good to know. I’m sure you won’t be the only person affected.

1 Like