[Unit]
Description=Automount samba server
[Automount]
Where=/home/esom
TimeoutIdleSec=600
[Install]
WantedBy=multi-user.target
I enabled the automount unit and it seems to work fine. Every time I access /home/esom, it will mount the samba share for me.
However, after the successful setup, the automount unit failed to work at the next time I turned on the computer. Entering /home/esom shows empty folder. I need to restart the automount unit by
to make the automount works until the next boot.
Does anyone know what keeps the unit from working automatically? I check the unit status on a fresh boot and it shows the unit was loaded, active, and waiting, so I suppose it was successfully loaded, but didn’t work for some reason.
Any advice would be appreciated.
I assume that esom is your username - essentially when mounting a share onto a folder with existing files you will hide the existing files with the content from the share.
There is another method which makes use of gvfs and thus does not require any system modifications to work.
Hi,
Thanks for your reply. I created a folder called /home/esom specifically, which doesn’t belong to any user. The reason is I want to keep my / tidy.
When rebooted and you are logged in - navigate the folder - /data/esom
If your system behaves as expected - using the /data/esom mount point - then you know that your other choice of mountpoint is directly causing your malfunction.
I actually had the same problem, but i was doing it via fstab so i am not sure how much it is applicable to your issue.
SInce you seemingly want to run a homefolder over network i think the WantedBy is ok otherwise i would get rid of it. Also, since it is over network you should add
After=network.target
Requires=network.target
to the mount file under the [Unit] tag. I also added the vers under Options.
For reference here are the units that got generated by systemd from my fstab:
Mount Unit:
Normally you would not need even that, since systemd has a list of filesystems, that it automatically assumes for, that they need network access afaik. In any case there is no harm done by specifying either of it.
It was producing longer startup time and a lot of errors in the log.
It turned out that adding network.target to a mount unit created a dependency loop which would be removed by only using _netdev - which would cause systemd to create the correct dependency tree.
Hi,
I change the mount point to /data/esom and now it works without restarting the service. It’s really strange that things can happen like this even the permission of the two folders are the same. @linux-aarhus maybe you can edit the tutorials about this notion.
If one wants to deviate and create another structure - it is your system - thus your decision.
The tutorials all uses the /data/ tree - and I can see no reasonable explanation to why your initial mountpoint didn’t work. I have explanation - I have an idea but it is far fetched.
This is purely guess work - I guess it didn’t work - could be because the /home tree is an important location for the system. Maybe systemd assumes that folders mounted in /home is a users home and it is entirely possible to have a networked home.
There is a service called systemd-homed which allows for portable home folders. If a folder is mounted inside /home - systemd may just think - this is a user’s home - but I have no user with them name - just to be safe I won’t allow mounts which is not a user’s home.
As there is no explicit rules as to which structure you can choose - although there is some locations which should be avoided due to they volatile nature or specific use.