Crash when opening mounted shared volumes containing nested dir structure
Netatalk v4.1.0 crashes when trying to open my mounted home folder.
This happens with both BasiliskII with MacOS 7.6.1 and QEmu with MacOS 9.2.2.
Wonder if this also has something to do with libxml, since the home folder contains the folder "Hämtningar" (Downloads)...
Running on Ubuntu 20.04.6 LTS
My afp.conf:
; Netatalk 4.x configuration file
;
[Global]
; Global server settings
appletalk = yes
log file = /var/log/netatalk.log
log level = default:debug
[Homes]
basedir regex = /home
[Mac_backup]
path = /home/administrator/Mac_backup
[Storage]
path = /home/administrator/Storage
Logs netatalk.log
GDB trace:
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: Filen eller katalogen finns inte.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3e8c0c6859 in __GI_abort () at abort.c:79
#2 0x000055674af476f3 in dircache_add (vol=0x556779bc0bd0, dir=0x556779bcc4e0) at ../etc/afpd/dircache.c:439
#3 0x000055674af4a797 in dir_add (vol=0x556779bc0bd0, dir=0x556779bcc3a0, path=0x7fff85201c60, len=10)
at ../etc/afpd/directory.c:797
#4 0x000055674af50337 in enumerate
(obj=0x55674afb4840 <dsi_obj>, ibuf=0x7f3e888da024 "strator's homegP{Y\215\202%\227с\215W\337\344\250\020\320n5\362\071\061\rqv\357\351c'\362I\315j\376\233\030\036s\217\243cC\026T\310i\217N", <incomplete sequence \321>, ibuflen=20, rbuf=0x556779b9fdd0 "\a\177\023\177\200", rbuflen=0x556779bafdd0, ext=0) at ../etc/afpd/enumerate.c:390
#5 0x000055674af5080a in afp_enumerate
(obj=0x55674afb4840 <dsi_obj>, ibuf=0x7f3e888da010 "\t", ibuflen=20, rbuf=0x556779b9fdd0 "\a\177\023\177\200", rbuflen=0x556779bafdd0) at ../etc/afpd/enumerate.c:488
#6 0x000055674af3a7fd in afp_over_dsi (obj=0x55674afb4840 <dsi_obj>) at ../etc/afpd/afp_dsi.c:623
#7 0x000055674af6cf5b in dsi_start (obj=0x55674afb4840 <dsi_obj>, dsi=0x556779b9f6e0, server_children=0x556779b95b10)
at ../etc/afpd/main.c:536
#8 0x000055674af6cb6d in main (ac=4, av=0x7fff852020c8) at ../etc/afpd/main.c:469
This is likely due to creating nested volumes in your home folder. Add vol dbnest = yes under [Global] in your configuration and see if it solves the problem. Otherwise, move the Mac backup and storage shares to another location out of the home directory. On Linux, shares are typically located under the /srv folder.
Tried uncommenting all shares in afp.conf except home, still crash. Added the vol dbnest = yes with only home share active, still crash.
Can you please try creating a "afp-data" subdir in your home dir, then update afp.conf with:
[Homes]
path = afp-data
basedir regex = /home
This will ensure you have a clean shared home volume, so that we can exclude any other environmental factor.
This callstack looks identical to the one I ran into in https://github.com/Netatalk/netatalk/issues/1235 which makes me agree with NJRoadfan's assessment that the root cause is traces of nested netatalk volumes.
@pbobbenb But first, I'd appreciate if you could check out this branch and see if the added error logging will trigger just before the crash: https://github.com/Netatalk/netatalk/pull/1897
If you see the new "dircache_add(): did:%u is less than the allowed %d. Data in \"%s\" may be invalid." log message this will confirm my theory.
Its likely that once you nest folders, some old invalid CNID values are hanging around on files in folders. Running sudo dbd -f /home/administrator/ should force recreation of the CNID database and remove those now invalid values.
I added a hint about rebuilding the CNID database to the error log message.
Yes, the error message shows up:
Jan 19 00:23:51.367893 afpd[58642] {dircache.c:441} (error:AFPDaemon): dircache_add(): did:2 is less than the allowed 17. Try rebuilding the CNID database for: "Mac_backup"
Did try the sudo dbd -f thingy, but still crashes.
Good to know that the logging works as expected! I tried to reproduce today with various patterns of nested shared volumes, but could not trigger the fail state after an hour of trying...
Can you please share the exact dbd command and the terminal output that you got?
Even though I specify the folder for dbd, it still goes through the whole home folder, is that because dbd reads the configured shares in afp.conf or ? Right now only the home share is activated.
The other thing is it says nested .AppleD* in Mac_backup, there are no such files or directories in that folder, or is it reading stuff from /var/local/netatalk/CNID even though vol dbnest = yes is set in the config ?
sudo dbd -ft /home/administrator/Mac_backup
CNID mismatch for '/home/administrator/Mac_backup/Network Trash Folder', CNID db: 517, ad-file: 446
Scanned: 10000, time: 587 s
Scanned: 20000, time: 1078 s
Scanned: 30000, time: 1539 s
Scanned: 40000, time: 2010 s
Scanned: 50000, time: 2558 s
Scanned: 60000, time: 3111 s
Scanned: 70000, time: 3744 s
Scanned: 80000, time: 4322 s
Scanned: 90000, time: 4892 s
Scanned: 100000, time: 5470 s
Bad filetype: /home/administrator/.pcsc10/pcscd.comm
Nested .AppleDesktop in /home/administrator/Hämtningar/Mac_backup
Nested .AppleDB in /home/administrator/Hämtningar/Mac_backup
Scanned: 110000, time: 6089 s
CNID mismatch for '/home/administrator/Storage', CNID db: 34749, ad-file: 2
CNID mismatch for '/home/administrator/Storage/Davinci', CNID db: 34780, ad-file: 590
CNID mismatch for '/home/administrator/Storage/Davinci/2024-12-11 13-29-25.mkv', CNID db: 34781, ad-file: 592
CNID mismatch for '/home/administrator/Storage/Davinci/2024-12-17 23-10-00.mkv', CNID db: 34782, ad-file: 591
CNID mismatch for '/home/administrator/Storage/Davinci/2024-12-18.mp4', CNID db: 34783, ad-file: 593
CNID mismatch for '/home/administrator/Storage/APPLE SD Card Reader Media.dmg', CNID db: 34784, ad-file: 594
Scanned: 120000, time: 6739 s
CNID mismatch for '/home/administrator/TheVolumeSettingsFolder', CNID db: 46100, ad-file: 20
Tried the path = afp-data in homes and that works when opening the mounted home share.
Well, this is a bit odd, changed the name of the folder Mac_backup to Mac_backup2 but still getting crash and now it said Mac_backup2 in the crash log, even though I didn't change the share name or path in afp.conf! How could it know I changed the folder name?
Anyway I then changed it to test and now I could open the mounted home folder. Then I thought, maybe it has some thing to do with under score in the name, so I renamed the folder to Mac-backup and activated the Mac_backup share with changing the path only and I can mount the home folder share no crash. Then I renamed the folder back to its original name Mac_backup and what do you know, I can still mount the home folder and I even turned off vol dbnest = yes and it still works!
But yes, having the other shares inside the home folder share is probably not a good thing, don't know what kind of side effects that might bring. Easiest for me is to just disable the home share, don't really need it, but might be a good idea to put in place something to prevent nested shares for others that might try the same thing. Maybe something that checks to see if there are shares below/inside other shares and throw up a warning that this is not recommended, but don't know how difficult/easy that would be, since I'm not a programmer...
Note to self: I'm going to improve on the Configuration chapter in the manual to cover best practices, including the avoiding of nested volumes.