Dietpi-drive-manager behaviour when remote shares not present

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version G_DIETPI_VERSION_CORE=8
  • Distro version G_DIETPI_VERSION_SUB=25
    G_DIETPI_VERSION_RC=1
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
  • Kernel version Linux XXXXX 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux
  • Architecture amd64
  • SBC model VM install on Proxmox
  • Power supply used N/A
  • SD card used | N/A

Steps to reproduce

  1. My dietpi install had 4 remote drives mounted locally (SMB and NFS) that were defined using dietpi-drive-manager.
  2. I do not want those remote drives mounted on my box.

dmesg reported continously:

[ 7332.281817] CIFS: Attempting to mount //192.168.X.XXX/AAA/BBB
[ 7338.414996] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 7338.415035] CIFS: VFS: Error connecting to socket. Aborting operation.
[ 7338.415401] CIFS: VFS: cifs_mount failed w/return code = -113
[ 7338.415663] CIFS: VFS: cifs_mount failed w/return code = -113

Expected behaviour

  • I expected to run dietpi-drive-manager to “uninstall/inactivate” those shares
  • Dietpi-drive-manager after reporting valid errors as those shares are not available, does not show any defined remote share on the system. It seems there is no shares defined, so no way to “delete” those connections, reporting continoussly errors

Actual behaviour

  • No option to remove those shares from /etc/fstab

Extra details

  • I manually commented out remote shares from /etc/fstab but I am not sure if is that it or there is something pending maybe affecting my system performance.

I respectfully suggest to include that option or provide instructions to manualy remove.

Best Regards, happy new year and thanks for dietpi. I love it.

removing the entries from /etc/fstab should be enough. Nothing else to do.

1 Like

What happens if you start dietpi-drive_manager?
Did you wait for a couple of minutes for this?

I mostly use NFS and see that in case of missing shares the start of dietpi-drive_manager takes a longer time.

should be 90sec until timeout.

90 sec for every missing share?

I guess.

Yes. it takes that time. But some performance is affected. For instance, and it is weird, vim takes a longer time to close editing a file. I assume others functions can be impacted.

If you remove these entries and reboot your system, all should be fine.

1 Like

An option would also be to wait for dietpi-drive_manager started and then remove the shares therein.

That is exactly what I was reporting. After waiting for diepi-drive-manager to start, no option to “remove” those shares as they were not connected was available. /etc/fstab should be checked. It is not something critical, as just editing /etc/fstab to remove them is enough. That could be suggested on dietpi-drive-manager.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.