We have an internal application with systemd services that we want to deploy outside of the normal systemd directories (/etc/systemd/system and /usr/lib/systemd/system). That location is on another disk (/mnt/data in the example).

The systemd service is enabled by:

systemctl enable /mnt/data/sprinterd.service

which creates a symbolic link in /etc/systemd/system

lrwxrwxrwx. 1 root root   27 Jun 20 22:47 sprinterd.service -> /mnt/data/sprinterd.service

After rebooting, the service is not loaded because the unit file can't be found. From journalctl, first an error that the service failed to load, then after that the mount of the disk where the unit is located.

Cannot add dependency job for unit sprinterd.service, ignoring: Unit sprinterd.service failed to load: No such file or directory.
systemd[1]: Mounted /mnt/data.

From /etc/fstab:

/dev/disk/by-uuid/c55e944f-5c63-48ad-8cd2-bd32d7b35c82 /mnt/data auto nosuid,nodev,nofail,x-gvfs-show 0 0

For completeness the service unit file:




I have tested this on RHEL 7 and on openSuSE 13.2.

Is it supported to have a system service unit file on another disk than /etc or /usr? How could the order of execution between mounting the disk and loading the systemd unit files be changed?

  • Requires=mnt-data.mount...
    – jasonwryan
    Commented Jun 21, 2016 at 8:42
  • nope, still the same. mounting /mnt/data happens after systemd loads the unit file.
    – nickvane
    Commented Jun 21, 2016 at 8:49
  • I think Requires, After, and RequiresMountFor are taken into account for when the service is started, but not for when it is loaded.
    – nickvane
    Commented Jun 21, 2016 at 9:25
  • 7
    The problem is that the files in /etc/systemd are symlinks and so when systemd starts up it tries to read and parse them before any filesystem is mounted; because the filesystem isn't mounted the symlink doesn't refer to a valid file and so the service isn't loaded. I'd love to know an answer to this 'cos I have units I'd like to be loaded from an NFS server and suffer the same problem; to date I've had to copy the unit to the root partition and enable that :-( Commented Jun 21, 2016 at 12:23
  • @StephenHarris That's systemd to you, Stephen. I'm having exactly the same problem also.
    – alecov
    Commented Dec 24, 2017 at 3:34

2 Answers 2


As explained by @StephenHarris the problem is at the moment systemd tries to read the unit, the file that's symlinked isn't available yet

To just have systemd reload the units after it has mounted :

Description=reloads units stored in /mnt/data

ExecStart=/bin/systemctl daemon-reload


This will cause the units to become available, because this time this time the target of the symlinks is mounted.

But by that time, the list of jobs needing to be run to reach the default.target is already built, and the service won't be started.

To have it also restart your service:

Description=restart unit stored in /mnt/data

ExecStart=/bin/systemctl daemon-reload
ExecStartPost=/bin/systemctl start sprinterd.service



  • I've tested with ExecStart= & ExecStartPost=, but it should obviously work with ExecStartPre= & ExecStart=
  • if it's all about 1 single unit, you might as well : ExecStart=/bin/systemctl enable /mnt/data/sprinterd.service instead of daemon-reload
  • if there are multiple services, do the daemon-reload, then start a single unit that uses ConsistsOf= or PartOf= to load all the multiple services.
  • If its NFS (or other networked system), of course local-fs.target isn't your best Installation option, obviously.

For a more old-school SysVinit-style approach, put the systemctl commands inside /etc/rc.local and chmod +x that file.

And then go smuggly post on Devuan's mailing list how you needed SysVInit to fix b0rked SystemD ;-)


This is a known limitation. Wish I had a workaround for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .