Kernel version | Linux XXXXXX 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021 aarch64 GNU/Linux
SBC model | Odroid N2 (aarch64)
Power supply used | 12V 2A
SD card used | Sandisk Ultra
Extra details
Hi! New forum web interface…is very different from what I am used to!
I am not a newbie or an oldbie , so if the solution is obvious/simple please be kind.
I have an Odroid N2+ which I am trying to do a simple NAS with Samba. This unit is setup as a VNC using a Mate desktop.
I have run into several problems. I attached a thumb drive to the unit which had two partitions, vfat and ext4. I used “dietpi-drive_manager” to connect this thumb drive to the system. Both of the partitions on the thumb drive are sited in "/etc/fstab " using “/media” as the target mount point.
eg:
/media/vfatdrive
/media/ext4drive
I can see/use the thumb drive partitions via ssh or VNC client. So I used the same mount points as entries in smb.conf as I wished to be able to see those thumb drive partitions from other computers.
The use of samba results in complete failure to achieve a permitted connection. I edited “smb.conf” with any parameters I could think of without any luck. But I noticed that the default “/mnt/dietpi_userdata” in “smb.conf” did connect!
I edited "/etc/fstab and changed the mount points of the thumb drive from “/media” to “/mnt” and of course replacing “noauto” with “auto”. After refreshing both the mounts and samba service I was able to connect to both partitions of the thumb drive on an external computer. However the vfat partition remained read only in samba. Is there anyway to allow a vfat partition to be rw in samba? I could not find a way to do this. This is very frustrating because Windows does not natively support ext4, etc. only ntfs and fat. I do not have this problem with Raspbian on a RPI3.
I gave up and for now I moved/reformatted the vfat partition to ext4. But then I noticed another problem. Everytime “dietpi-drive_manager” is invoked or drives are refreshed in that bash program, “/etc/fstab” is overwritten/destroyed. Which means that any hand edits that were made such as changing “/media” to “/mnt” in the mount statements are also “erased”. This requires logging back in via ssh/NVC to put those changes back to get samba to work again!
I do not know if you can mount a device to multiple locations, such as both "/mnt " AND “/media” or whether this is a good idea for security reasons. I suppose some simple bash file could be used to remount those thumb drive partitions on every boot, but I am out of luck if I use “dietpi-drive_manager” by accident without rebooting. Samba will stop working again.
Thanks for reading this, I hope there is a solution.
You are right, dietpi-drive_manager overrides the fstab, so simply mount it just with dietpi-drive_manager to /mnt/ext4drive. This is persistent.
If you want to make this path also accessible somewhere else, you can create a symbolic link:
ln -s /mnt/ext4drive/ /media/ext4drive/
The external drive would be now accessible from both paths. But this is not necessary since you can simply change the path in the smb.conf.
If you want to create more samba shares, just make another copy of the config section, like seen below (I copied the [dietpi] section from my testsystem, I’m not sure if this is the default dietpi config, I may have changed it already in the past):
It’s also maybe necessary to use the share with root user (valid users =), it depends on the permissions of the external drive, I guess. Maybe this was even your problem with your attempt with the vfat file system. It may also be neccessary to give the root account a samba password with smbpasswd -a.
I have looked at “dietpi-drive_manager” carefully, but there is no option that allows me to control where the thumb drive is mounted. It always defaults to “/media/root”. The only way to change the mount point is to edit fstab directly. As mentioned every time “dietpi-drive_manager” is invoked, whatever changes were made to fstab are clobbered. It reverts back to “/media/root”. Am I missing something here, please explain?
This might work as long as the symbolic link survives a reboot, I did not think of this. I cannot reboot the dietpi setup in question till the end of this week. So I will have to try it then. This seems like the only way to bypass what “dietpi-drive_manager” does without damaging the connection in Samba.
Yes, I am forced to do this, a manual edit in nano/pluma. Thankfully that edit is permanent/persistent!
Yes, this is how I created the various shares in “smb.conf”. I did not think to specify “valid users = root”. The vfat partition was visibly owned by root, as seen in “caja” in my Mate desktop setup for the system in question. It was NOT possible to change permissions for that partition at all. It is odd that not even root can change the permissions for a vfat drive, which seems to be the default for dietpi. Giving the root account a samba password is something I have not tried. The only way to re-create the vfat read only through samba would be to plug in another vfat thumb drive. As of this writing the path of least resistance for the diepi setup was to use ext4, but Windows cannot write to that thumb drive directly.
Ok maybe this behaves different on Odroid, but when I mount e.g. pen drives or external disks with dietpi-drive_manager, I’m in the particular menu (mount, check&repair, format etc) of the drive I wanna mount and when I hit “mount” there’s a prompt where I can edit the mountpoint. This not happens in your case?
Symbolic links are also persistent. I linked some stuff for a webserver and it survived several reboots
The way “dietpi-drive_manager” behaves here is that when the script is invoked drives that are plugged in to the unit (USB port) are immediately mounted. There is no choice for path given! I am pretty sure that if another thumb drive is attached and “dietpi-drive_manager” is already running, that the “Refresh” “Scan for recently added/removed drives” would automagically assign the /media/root path, no choice allowed! What SBC and version are you using? Maybe the script code is different for “dietpi-drive_manager”. Maybe your version can be adapted to work on the Odroid?
To avoid misunderstanding. There is no difference on dietpi-drive_manager in relation to the SBC used. It should behave same always.
Depending on the settings inside /etc/fstab, dietpi-drive_manager will behave differently.
If a USB drive is already configured inside /etc/fstab, it will be mounted to the given mount point given.
If the drive is not configured inside /etc/fstab, the drive will just display as unmounted, and you have the option mount
Anyway, even if a drive is already mounted, you have the option to unmount and mount again. Performing the mount step, should ask on the specific mount point you like to attach the drive.
Yes, one more clarification. By default, and with dietpi-drive_manager NOT running or having been invoked, when a thumb drive, etc is inserted into a USB port, it is auto mounted by another process that the user has no control over. At least this is the case with the Mate desktop (gnome). The default auto mounted device will be in /media/root…which is a source of trouble if the intent is to be used with samba.
I discovered today that either you edit fstab manually to the mount point that samba can access/use and re-mount with mount -av, or you have to un-mount and re-mount that device in dietpi-drive_manager, specifying a directory that samba can access when you re-mount.
Any direction on how to get a vfat partition to be shared on a LAN through a SBC with dietpi would be most helpful/appreciated. In my OP, I had no luck.
This is what I found with gsettings list-recursively
I might have to also set automount-open to false?
I will have to setup a diff thumb drive to try this out, as I do not wish to disturb what is already working in samba.
Thanks!
PS: I elected to use Mate, because at the time, many months ago, nothing else (Desktop) would install properly from the software menu with that dietpi version/img for the Odroid N2+.
gsettings set org.mate.media-handling automount false
gsettings set org.mate.media-handling automount-open false
gsettings set org.gnome.desktop.media-handling automount false
gsettings set org.gnome.desktop.media-handling automount-open false
Yes, as a VNC. In short it gives other older systems (unsupported Windows O/S etc) access to the internet through a cheaper/more secure SBC. In my world there are certain software packages that are x86 Windows only, that are partially broken with newer Windows versions. At this time I refuse to migrate to Win10/11/xx for intrusive spyware reasons. Not to mention forced updates that remove/wreck installed software at Microsoft’s whim!
A VNC link requires very little software/RAM on the client side to access unlike something like OpenBox or VMware. Some things like video calls or youtube are not really possible, but I have other SBCs that can do that job for me locally. Like this SBC I am writing to you on.
Thanks so much, I now have a plan to try out this weekend, hopefully the mystery and headache will be solved for USB mounted EXT4 drives. Any ideas for allowing VFAT shares to be RW over the LAN?
