Bug 2360947

We already set the folder using RuntimeDirectory in the service file:
https://src.fedoraproject.org/rpms/netatalk/blob/rawhide/f/netatalk.spec#_166

That creates the path when the service is started. 
Please verify you are using the service file provide by the package and the line referenced above exists.

Something isn't right, however. The path you have provided, /run/lock/netatalk/netatalk/netatalk, is not correct.

The full path to the pid file should be /run/lock/netatalk/netatalk

I need to check if upstream may re-defined the with-lockfile-path build parameter. I'll have to investigate, time permitting.

(In reply to Andrew Bauer from comment #1)

> That creates the path when the service is started. 
> Please verify you are using the service file provide by the package and the
> line referenced above exists.
> 

I did originally have the service file from the package, I've pasted the original below:

```
# This file is part of Netatalk 4.1.2.

[Unit]
Description=Netatalk AFP fileserver for Macintosh clients
Documentation=man:afp.conf(5) man:netatalk(8) man:afpd(8) man:cnid_metad(8) man:cnid_dbd(8)
Documentation=https://netatalk.io/
After=network.target avahi-daemon.service atalkd.service

[Service]
Type=forking
GuessMainPID=no
ExecStart=/usr/bin/netatalk
RuntimeDirectory=lock/netatalk
PIDFile=/run/lock/netatalk/netatalk/netatalk
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target
```

Yep, no rush on my end - I have a work around.

Also, changing the RuntimeDirectory as below also fixes the issue:

RuntimeDirectory=lock/netatalk/netatalk

I think the best solution is to adjust with-lockfile-path during build, so we don't end up with nested netatalk subfolders. 

This looks like the relevant PR that changed the behavior of the with-lockfile-path parameter:
https://github.com/Netatalk/netatalk/pull/1850

If the weather keeps me inside on Saturday, I spend my time working on a fix for this.

FEDORA-2025-015c5a157e (netatalk-4.2.1-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-015c5a157e

FEDORA-2025-015c5a157e (netatalk-4.2.1-1.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2025-3538438f4a (netatalk-4.2.1-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-3538438f4a

FEDORA-2025-e89778e77b (netatalk-4.2.1-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-e89778e77b

FEDORA-2025-e89778e77b has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-e89778e77b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-e89778e77b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-3538438f4a has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-3538438f4a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-3538438f4a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

*** Bug 2362265 has been marked as a duplicate of this bug. ***

FEDORA-2025-3538438f4a (netatalk-4.2.1-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2025-e89778e77b (netatalk-4.2.1-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.