cptactionhank / docker-netatalk Goto Github PK

Great work on this image!

Would it make sense to run the avahi daemon in a separate container so you would have to set the option --net=host only on the avahi container to limit the security concern.

At the same time you can then get rid of supervisor and run only netatalk.

Moving large folder errors out: not enough free space (I have over 500 GB).

Might be a netatalk issue? Anyone have any ideas?

I'm trying to set up Netatalk as a container on my Unraid server, and I have manually set all 4 environment variables, and the path for my share, but when running the container, the log just spits out the following error every second until I terminate the program.

May 07 22:09:42.947195 netatalk[1] {netatalk.c:262} (note:AFPDaemon): Restarting 'cnid_metad' (restarts: 281)

Also attached is my docker config, is there something I'm missing?

Thank you for you work on this image.

It will be great to disable guest login with some environment variable. What do you think about it?

Seems currently you have to specify a uid and a gid at startup of the daemon. I guess this is not necessary since users should be added/modified in afppasswd? I guess afppasswd should be a volume and we can run "docker exec -ti" to add a user, modify a user, right?

When restarting an existing container, the entrypoint script attempts to recreate afpuser even if it already exists:

groupadd: group 'afpuser' already exists
adduser: The user `afpuser' already exists.

Also, the netatalk daemon exits immediately upon startup with a cryptic error message. It's possible that this is related to the above error, or it could be a totally separate problem.

netatalk is already running (pid = 1), or the lock file is stale.
exited with code 3

To reproduce, simply stop and start the container a few times. I am running via docker-compose, but I don't think that matters.

Seeing the following in docker logs:

Dec 01 03:59:42.155559 afpd[3678] {quota.c:646} (info:AFPDaemon): getquota: special /media/timemachine fails

Problem:
When the server is first made with the AVAHI=1 flag, the process list looks something like this, and your computer is automatically discoverable by Finder, thus appearing on the left-hand navigation bar.

I'm starting from accessing the container (docker exec -it netatalk /bin/bash or similar).

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0 147912  6068 ?        Ssl  08:06   0:00 netatalk -d
message+    15  0.0  0.0  42124  2188 ?        Ss   08:06   0:00 dbus-daemon --system
avahi       18  0.0  0.0  32488  3096 ?        S    08:06   0:00 avahi-daemon: running [ubuntu.local]
avahi       19  0.0  0.0  32100   256 ?        S    08:06   0:00 avahi-daemon: chroot helper
root        20  0.4  0.0 141000 10320 ?        S    08:06   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5832 ?        S    08:06   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        23  0.1  0.0  20224  3204 ?        Ss   08:06   0:00 /bin/bash
root        37  0.0  0.0  17500  2072 ?        R+   08:06   0:00 ps aux

When you reboot the server, or something unexpected happens, the server doesn't appear as before in the left-hand side bar, though you can still mount it by IP address. The process list looks like this:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.3  0.0  74180  6232 ?        Ss   08:09   0:00 netatalk -d
root        21  0.8  0.0 141000 10472 ?        S    08:09   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        22  0.0  0.0  67380  5820 ?        S    08:09   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        23  0.5  0.0  20232  3240 ?        Ss   08:09   0:00 /bin/bash
root        32  0.0  0.0  17500  2184 ?        R+   08:09   0:00 ps aux

Therefore, the avahi-daemon and dbus services aren't being restarted along with the other services.

Temporary Solution:
Running service dbus start then service avahi-daemon start then kill -1 1 (PID 1 for netatalk -d) resolves the issue until the next boot/error. Running services:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0 147912  6336 ?        Ssl  09:05   0:00 netatalk -d
root        20  1.0  0.0 141184 10340 ?        S    09:05   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5756 ?        S    09:05   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        22  0.0  0.0  20248  3260 ?        Ss   09:05   0:00 /bin/bash
message+    43  0.0  0.0  42124  2188 ?        Ss   09:05   0:00 /usr/bin/dbus-daemon --system
avahi       60  0.1  0.0  32364  3200 ?        S    09:06   0:00 avahi-daemon: running [ubuntu.local]
avahi       61  0.0  0.0  32100   256 ?        S    09:06   0:00 avahi-daemon: chroot helper
root        63  0.0  0.0  17500  2132 ?        R+   09:06   0:00 ps aux

20 and 21 are save to kill as well, which makes the two working models rather comparable. Obviously, however, this solution is nonideal for most use cases.

Suggested Solution:
I think it would be wise to enable these services from the Dockerfile or entrypoint. Running update-rc.d dbus defaults along with update-rc.d avahi-daemon defaults gives the following output:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.6  0.0  74180  6092 ?        Ss   09:10   0:00 netatalk -d
avahi       18  0.0  0.0      0     0 ?        Z    09:10   0:00 [avahi-daemon] <defunct>
avahi       19  0.0  0.0      0     0 ?        Z    09:10   0:00 [avahi-daemon] <defunct>
root        20  5.3  0.0 141000 10384 ?        S    09:10   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5688 ?        S    09:10   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        22  1.0  0.0  20248  3264 ?        Ss   09:10   0:00 /bin/bash
root        30  0.0  0.0  17500  2128 ?        R+   09:10   0:00 ps aux

avahi-daemon doesn't start running, try as it may, because dbus never starts. Log entry generated:
Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
Removing /var/run/dbus/pid and rebooting indeed seems to fix the issue.

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.6  0.0 147912  6100 ?        Ssl  09:19   0:00 netatalk -d
message+    17  0.0  0.0  42124  2256 ?        Ss   09:19   0:00 dbus-daemon --system
avahi       20  0.3  0.0  32488  2980 ?        S    09:19   0:00 avahi-daemon: running [ubuntu.local]
avahi       21  0.0  0.0  32100   256 ?        S    09:19   0:00 avahi-daemon: chroot helper
root        22  4.3  0.0 141000 10412 ?        S    09:19   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        23  0.0  0.0  67380  5832 ?        S    09:19   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        25  2.0  0.0  20252  3040 ?        Ss   09:19   0:00 /bin/bash
root        32  0.0  0.0  17500  2076 ?        R+   09:19   0:00 ps aux

This solution isn't permanent since the file will reappear after every boot. In the Dockerfile, I tried using the command service dbus start since it seemed to gracefully remove the pid file when run manually.

# service dbus start 
Removing stale PID file /var/run/dbus/pid..
Starting system message bus: dbus.

So far the results are good. Replacing avahi-daemon -D with service avahi-daemon start might be a good idea as well, given these findings.

Conclusion
I suggest using service dbus start in place of dbus-daemon --system in the Dockerfile to more gracefully handle the destruction of the stale PID file /var/run/dbus/pid, which appears to cause issues with dbus and by extension avahi when restarting the container.

Currently we can pass username and password via ENV vars : AFP_USER and AFP_PASSWORD. The owner for directory /media/share is set to AFP_USER in docker-entrypoint.sh.

But what if I want to provide multiple shares (volumes), with different users for each ? The ENV var being unique it impossible to provide multiple users (along with their password). The only way to have multiple users is to run more docker containers of docker-netatalk with different ENV vars.

Would be good if there were ENV vars AFP_USERS and AFP_PASSWORDS which would actually be arrays. And owner for shares should be set per volume basis, based on which users are have access to the volumes defined (in the afp.conf file), not just for /media/share.

Looks like you did a commit to bump version to 3.1.11, but it was only the ENV variable. Everything else in the Dockerfile is hard coded to 3.1.8 and doesn't reference that variable.

I already have timemachine running from another container. Would be nice if there was a simple flag I can pass to docker run to disable timemachine so I do not have to mount an empty volume each time.

I wanna time machine server 💯

It would be cool to support multiple users.

This could be archived by:

• A mounted configuration file/directory (in the best case make the path configurable in the variables)
• A regex on the docker variables

Hi,

Is this container reusable?
Do you have any manuals somewhere?

Thanks

I've made docker-compose.yml in which I specified AFP_USER and AFP_PASSWORD. docker inspect reports that variables are successfully defined. However still can't log in.