The systemd services that are described in this thread are run by systemd witch has credentials to run as root, kinda, it will be able to mount is what I’m going at. A script is run by the user starting it, so if you want to start it as root you have to start it with sudo, and you don’t do that “easily” in a graphical interface, for good reason.
So there is no need to make a script for you to run in the first place, what you want to do is make a SERVICE (run by systemd) that handles it for you and above is described how to.
Otherwise this describes exactly what I think you want. Just change what is needed and remove what is not (if it’s an ntfs change from cifs to that and remove login credentials f.ex)
after [Unit] in your path-to-mount.mount file if it’s a network mount so you know that networking is up and running before it tries to mount.
You don’t even need anything in fstab with this setup.
But if you REALLY want to use a script and fstab I think you can add user in the options for the drive in your fstab. The option user gives permission to users to mount so your script MIGHT work, not to sure about umount and user privileges.
Thank you bedna for the idea of not using the script.
Just changing what is needed is more complicated than it sounds since I don’t understand some of the things required. Besides that, I don’t think that this is what I want because I want a conditional mount since fstab mounts the drive most of the times.
I have created a file on the drive (present.txt). My scripts checks for the existence of the file. If not, the drive is not mounted and then it mounts.
if [[ -f /home/frank/Data/present.txt ]]
result=“Did not have to mount drive.”
mount -t ntfs -o umask=0000,gid=frank,uid=frank,windows_names /dev/sda8 /home/frank/Data
result=“Had to mount drive.”
echo “$result $(date +”%d-%b-%Y %H:%M")" > /tmp/ram/remount.txt
Edit. Now that I read your options you should probably change umask to dmask and fmask instead. I think umask is depricated? And is there a reason for the 0000? 0022 in mask mean 755 credentials (-rwxr-xr-x) and 0133 means 644 (-rw-r–r–), you remove the mask from 777 (full credentials rwxrwxrwx) so your 0000 means everyone has full control of everything so your uid and gid becomes meaningless, you might as well mount it with root credentials.
Adding noatime and nofail is also probably not a bad idea.
Thank you for those details. I understand that you mean to remove that drive from fstab and use those mount and automount files instead.
I don’t understand why the two.
Also, you mention that umask=0000 is a bad idea, but that is what you suggest in mount file. I admit I don’t fully understand all those -rw- r etc. It is a shared drive on my computer so other computers on the network also need access to all the files on the drive.
Is the last line of options in your post the options for the fstab?
I do prefer the fstab option, but of course with good options and it looks like I need to change what I have.
I am also thinking that the reason why fstab may have failed to mount that drive sometimes is because I had a file in /systemd/system from samba mounting the drive, maybe before stab, therefore stab would have failed. I don’t understand the order of the boot process to be sure about this.
The script doesn’t mount the share, but calls gio-mount
gio-mount location is predictable
This predicatablity is utilized to create a symlink
But you are making it complicated by mixing in your other experiments and thinking you need understand everything inside the script - you don’t.
If you do then great - but if you don’t it doesn’t matter.
The script has been up for a long time - it is - so to speak - vetted by the community to do precisely what it claims to do.
The script mount a samba share - as user - without any need for elevated permissions aka sudo or to run as root.
I’d advise you to remove all remnants of your previous experiments and just use the script when you need to mount the share.
If you later think - it would be nice the share is available automagically - you can create the systemd user unit - but this is not a requirement for the script to be functional.
Create the local bin folder
The topic explains you place the script in your home folder ~/.local/bin - if it does not exist - create it
Create the script
Open mousepad and paste the content of the script - then save the file - and when prompted for a name - navigate to folder .local/bin - it is hidden so if you cannot see the folder in the dialog - press ctrlh - navigate into .local → bin → provide the name you e.g. my-share.sh - the .sh extension is just a human helper to identify a shell script - the system doesn’t care
Make the script executable
chmod +x ~/.local/bin/my-share.sh
Amend a few script variables
The variable are there because not two usecases are alike.
# your samba server's hostname or IP address
# the share name on the server
# optional credentials
Then save the file
Open a terminal and type in the name of the file you just created.
If required - authenticate …
Navigate into the new SMBLinks folder in home → navigate into the share → do your thing.
If you have more than one samba share - it is easy to duplicate the script (and service if applicable)
Using the service brings in the benefit that symlinks are removed upon shutdown which otherwise may leave you with dead symlinks if the share is not mounted.
I have re-booted numerous times and as stated before I thing my problems were the fact that a file in systemd/system from samba requiring the mounting of my Data ntfs drive in opposition to fstab. So, the first one to mount the drive did it and other just stood by.
Now that I deleted that file, only fstab mounts the drive and appears to work fine.
megavolt spotted that problem early in this thread but needed time to re-boot numerous times to confirm that it was the problem.
I am fairly confident now that it is working fine.
Thank you to everyone else also for trying to solve my problem.
The only thing left for me to do is to correct the fstab entry for that drive.
Everyone here was against the umount=0000 entry and preferred the use of dmask and fmask. Here is the entry I avee settled on after all the comments:
linux-aarhus, if you read the first statements I made in my opening post:
"I have 2 ntfs drives normally mounted in my home directory. These drives are shared on my windows network and work fine when they mount in my home directory at boot time.
Sometimes, one specific drive doesn’t mount in my home directory but in /srv/samba/ntfs."
From there I was asking about when this does happen how do I unmount this drive and mount it where it should be, in the user directory.
megavolt actually found out why the drive was not mounted according to fstab. I was not able to confirm that his solution was correct because I had to wait until I rebooted the machine a large number of times and see that it does indeed mount at the correct location all the time.
This I have done now.
The other methods of mounting the drive would have been suitable if:
a) megavolt’s solution did not work, and
b) I was able to follow the method.
The alternative method to mount the drive correctly that I WAS able to follow (found on the web) was to place a file in the systemd/system folder to run my script with root permissions, stored in ./.local/bin folder. This also answered the question in the heading of this thread. This indeed does work and would conditionally mount the drive correctly if it did not mount during boot by fstab. Although this script runs on each boot, it has not had to mount the drive because fstab has done so correctly each time. I quoted the contents of the script in this thread as well.
I am new to linux and don’t understand some (maybe most) terms used here. The last is your term linux-aarhus, that you thought that this drive is a samba share drive and not a physical drive. I thought that a share drive was a physical drive. I am sorry about your misunderstanding, maybe you didn’t read the thread, just the heading.
Sorry, I have gone on too long.
As I stated in my last post, the only thing remaining is to confirm that my fstab entry is suitable for sharing the contents of this drive on my ethernet network with my other computers.
using systemd, to run a script at startup (I’m guessing you mean you place the script in ~/.local/bin) that mounts seems… not great (but if it works, go for it I guess). If you want to learn more about autorunning programs and scripts, look into crontab. @boot inside crontab also runs at boot. (not saying you should use it, just throwing out things to learn about in linux). Crontab Reboot: Execute a Job Automatically at Boot | phoenixNAP
What we are trying to explain is that systemd can handle the mounting altogether not needing fstab, witch will probably happen in this situation too.
I suspect the script contains something in the line of mount UUID=xxxxxx /home/username/mountdirectory, or are you mounting with mount -a in the script? If you are not using mount -a in the script, you can comment out (# in front or just remove the line) the line that mounts your drive in fstab and it should work anyway, fstab does nothing in that case.
It depends on when the script is run at startup, ie how your unit file in systemd is made (/etc/systemd/system/whateveryoucalltheunit.service), but I suspect it will run before fstab anyway.
You mount local drives, but you can also mount a network drive, that is what confused everyone. Ie, you can mount a local drive and then SHARE that drive with samba to OTHER users.
We thought you were trying to MOUNT a share that ANOTHER computer shared. The procedure is almost the same.
The reason I recommended using systemd with the path-to-mount.mount and path-to-mount.automount is because you mentioned it disconnects sometimes so you have to mount it again. Not sure if your script in ~/.local/bin is looped or if you only run it once, but with the method I suggested, the mount will get remounted automatically if it happens since the systemd service will run (mount the drive) every time the mount point is accessed by anything if not already mounted.
Both methods (yours and ours) utilizes systemd, but automount is a function built into systemd to be used for exactly this situation. I don’t use fstab any more, I only use systemd.
If your solution works, go for it!! What we are trying to explain is how it actually works and the “better” way to do it. You will have less operations/files to check if something fails f ex.
In reality, all you probably had to do was to change the unit file that samba used to mount (the one that pointed to the /run directory) to point to the right directory (~/) and that would probably have worked. But what you have done has taught you a few things right? And if it works for you, go for it!