Mounting shared folder to Debian with fstab

[Telos]

I need to mount a shared folder from Synology to my Debian installation. Using the mount command I am successful. But fstab is more vexing, and I see no content.

Using this mount command works:

sudo mount -t cifs -o rw,vers=3.0,credentials=/root/.smbcredentials //192.168.1.42/testing /media/share

Debian can read/write files hosted on the NAS.

According to a guide I followed, the corresponding fstab entry is:

//192.168.1.42/testing /media/share cifs vers=3.0,credentials=/root/.smbcredentials

I'm unsure there's actually a mount with this.

FWIW, I followed this post.

Hopefully, there is something simple I'm missing. Ideas?

 

[starfox101]

I use nfs, for the longest time I could not get it to mount using fstab. Found something that worked.
I could mount manually using: sudo mount 192.168.1.138:/volume1/disk1 mnt/synology/disk1. I think your missing the colon between ip and volume.
this finally work in fstab: 192.168.1.138:/volume1/disk1 /mnt/disk1 nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Hope that helped.

 

[Telos]

I think your missing the colon between ip and volume.

Thanks for the suggestion, however that had no result for me.

To bring closure to this, I had to employ automount as such:

//192.168.1.42/testing /media/share cifs rw,noauto,noauto,x-systemd.automount,vers=3.0,credentials=/root/.smbcredentials

I also added "rw" for good measure, though it did not seem necessary.

 

[EAZ1964]

As fas as I know you need to create the mount point in the /mnt folder, not in media.
You have to create /mnt/media first using mkdir /mnt/media

The lines in my fstab on kubuntu are less complicated: { i did not bother about the credentials file}
The kubuntu machine will connect to nas shared folder backup, with the mount point in /mnt/backup
//192.168.2.10/backup /mnt/backup cifs username=aaaa,password=bbbb, rw,uid=1000,gid=500 0 0

Try that first, then complicate it with the credentials file.
For SMB make sure the cifs packages are installed

 

[Telos]

As fas as I know you need to create the mount point in the /mnt folder, not in media.

Thanks! There is much talk about /media vs /mnt. Some say that /mnt should be used for temporary mountings.

Either way it should make no difference, IIUC.

When my fstab entry "failed" to connect, I saw that the problem was simply a timing issue, when using the mount command delivered the connection.

sudo mount /media/testing

That's what led me to the automount "solution".

Try that first, then complicate it with the credentials file.

The credentials file allows you to restrict who has access to credentials, instead of laying them out on the fstab. It's really quite simple. Give it a go.

 

[Deleted member 5784]

I see you've found a solution; just in case you were still curious what the issue with the original attempt was, you could try the following line in your fstab:

//192.168.1.42/testing /media/share  cifs  rw,vers=3.0,credentials=/root/.smbcredentials,file_mode=0755,dir_mode=0755 0 0

You can test if this works without rebooting by doing a

sudo mount -a

which should mount the share immediately.
In the past when an fstab entry has inexplicably failed to mount, the addition of the file_mode & dir_mode flags has often fixed the issue fo rme. It's to do with the configuration of the CIFS server (ie the syno)...can explain more if this fixes the problem!

 

[Telos]

in case you were still curious what the issue with the original attempt was, you could try the following line in your fstab:

Thank you. It's been a busy few days. I added the options you suggested, and they worked perfectly.

I have a secondary issue that I'm not dealing with. When rebooting Docker containers are starting before the mount is ready. When that happens, the container fails to run.

I've tried two approaches...

1. I switched from fstab to autofs based on related posts I came across. Unfortunately, that did not help.

2. Today I'm working on modifying docker.service, so that docker must wait for the mount. I'm unsure how that will play out.

Unfortunately, I'm now distracted by a collateral issue... Since I've changed mount points so many times, sonarr and radarr seem confused, and they have deleted random media., I'm re-doing their container configurations from scratch (I guess I'll be staying with autofs`).

Since Debian reboot is infrequent, I may live with manually restarting containers.

Thanks for your advice!

 

[Deleted member 5784]

Glad it worked.

The correct approach for the docker / mounting issue is the systemd service one. The mounts in your fstab aren't actually used to directly mount your filesystems on boot anymore; systemd converts these into systemd mount units which then run at boot.
Give this, you just need to find the name of the systemd mount service that is mounting your cifs share:

systemctl list-units --type=mount

It'll be something along the lines of mnt-<sharename>.mount

Then you can amend the docker service to only start after the mount unit has completed. In the docker service add the following to the [unit] section:

[Unit]
Requires=mnt-<sharename>.mount
After=mnt-<sharename>.mount

Do a sudo daemon-reload after changing the docker service file. The above causes the docker service to run the mount unit you need, and then wait until after this unit is running to start the docker service.

This should work - if not, it is at least the gist of it.

 

[Telos]

Hmmm... maybe I've already gone off in the wrong direction...

I started with sudo systemctl edit docker.service with the intention of adding:

[Service]
RequiresMountsFor=/mnt/syno /mnt/plex

Where "/mnt/syno" and "/mnt/plex" are the mount points used by my docker containers.

But nano gave me a strange file name...

So I bailed out... and later tried

sudo nano /etc/systemd/system/docker.service.d/override.conf

Which gave me a blank file into which I entered the "Service" option (above).

Have I messed up? If so, how do I undo this?

Thanks!

 

[Deleted member 5784]

If that is the only change you've made you can just delete the /etc/systemd/system/docker.service.d/override.conf file. Follow this with

sudo systemctl daemon-reload

which forces systemd to update with the change you've just made.

The dependency should go in the [unit] section of the systemd service (see my code above); this is where dependencies are defined.
Try my suggestion, which is to be done in the docker.service stystemd file (you'll have to look up where this is as distros put specific service files in different locations & I don't run Debian). Once you've made the change, follow it again with the systemctl daemon-reload code above to implement the changes.

If this doesnt work, you can simply re-edit the same docker.service file and remove the 2 lines i've suggested. Again, after any changes run a daemon-reload to update systemd.

 

[Telos]

Thanks @Fortran ... I'll give that a go tomorrow.

In the meantime... I deleted override.conf and located docker.service here...
/etc/systemd/system/multi-user.target.wants/docker.service

Hopefully, that's the one

EDIT1:
Located another using systemctl status docker here:
/lib/systemd/system/docker.service

I'm guessing that is the correct one

 

[Telos]

After countless reboots... A "workaround" victory.

I made the edits suggested for docker.service however they gave no success. Nor did the edit I wrote about:

[Service]
RequiresMountsFor=/mnt/syno /mnt/plex

What did work (kinda, sorta, maybe) was:

[Service]
ExecStartPre=/bin/sleep 30

After settling in with the 30-second delay, I returned docker.service to its original state, and instead, the 30-second delay to /etc/systemd/system/docker.service.d/override.conf

The reason for that is, should docker update, edits to docker.service may be overwritten. Using the override.conf file preserves customizations for docker.service (IIRC).

Not the most elegant solution... but a workable solution and impervious to changing mount points

 

[Deleted member 5784]

Not the most elegant solution... but a workable solution and impervious to changing mount points

It's amazing how many tricky concurrency issues in multi-threaded programming get fixed with a strategically placed 'sleep 10' or equivalent...hey, if it works, it works!