-
|
Describe the bug Just tested with 3.1.18 and it works with the same settings. To Reproduce netatalk:
image: netatalk/netatalk3
environment:
AFP_PASS: [secret]
AFP_USER: marcosvr
LANG: C.UTF-8
cap_add:
- NET_ADMIN
network_mode: host
volumes:
- /mnt/afpbackup:/mnt/afpbackup
- /var/run/dbus:/var/run/dbusExpected behavior Environment
|
Beta Was this translation helpful? Give feedback.
Answered by
rdmark
Jun 25, 2024
Replies: 10 comments
-
|
Thanks for reporting the issue. This is a strange one. I cannot see anything out of the ordinary in those logs... Does the same thing happen if you start a fresh backup on a fresh volume? And then subsequently run an update to the backup onto the backup volume? The main difference between the 3.1.18 and 3.2.0 Docker images is that the former uses Debian 11 and the latter Alpine 3.19. So perhaps some minute difference in the file system or AFP metadata on the volume, between the two Linux variants...? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Default log level running 3.2Default log level running 3.1.18I reverted to the default log level and ran both versions. Edit: I fixed it by adding Another issue found and fixed was: I added the following netatalk:
image: netatalk/netatalk3
environment:
AFP_PASS: [secret]
AFP_USER: marcosvr
LANG: C.UTF-8
cap_add:
- NET_ADMIN
network_mode: host
volumes:
- /mnt/afpbackup:/mnt/afpbackup
- /var/run/dbus:/var/run/dbus
security_opt:
- apparmor=unconfinedBut for this one I have some security concerns if this would be the right approach. I will try later to start a fresh backup and let you know! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@marcosvrs Actually, I was able to reproduce this issue... with the reverse case. Namely a backup volume created with the 3.2.0 Alpine based image, then switched to a 3.2.0 Debian based (experimental) image. I get the exact same "verification may have been interrupted by a network problem" popup, and no helpful log messages. Then when switching back to the 3.2.0 Alpine based image, the backup resumes without interruption. So there is something that Alpine does differently than Debian here. Maybe file system related? Anyhow, I kicked off a cross-compile image build now which will be pushed to Docker Hub in a few minutes. If you can kindly test the |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@marcosvrs Did you have a chance to follow up on this yet? We plan to put out a 3.2.1 release soon-ish, so any feedback that can help with bug fixes would be appreciated! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@rdmark I'm away from home those weeks. I will be back next week and then will test it! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@rdmark I can confirm it works like a charm 😄 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@marcosvrs Thanks for testing. This is both good and bad news. How disruptive would it be to you if you would have to redo your backups once for this version upgrade? (And never again for future versions.) Staying on Alpine rather than going back to Debian is highly preferable to this project... Alpine is a smaller and more secure base OS (the number of vulnerabilities reported by Docker Scout tells the story...) |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@rdmark Well, then I will need to make a backup of the backups, but it's fine for me 😄 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@marcosvrs Sorry about the trouble and extra work! BTW, are you using normal file sharing volumes as well? Are they working correctly after moving from 3.1.18 to 3.2.0? In my testing normal file sharing doesn't seem to be affected by this issue. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I put a compatibility notice on the Docker Hub description:
|
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
rdmark
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I put a compatibility notice on the Docker Hub description: