Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when opening mounted home folder #1893

Open
pbobbenb opened this issue Jan 17, 2025 · 11 comments · Fixed by #1897
Open

Crash when opening mounted home folder #1893

pbobbenb opened this issue Jan 17, 2025 · 11 comments · Fixed by #1897

Comments

@pbobbenb
Copy link

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
@NJRoadfan
Copy link
Contributor

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.

@pbobbenb
Copy link
Author

Tried uncommenting all shares in afp.conf except home, still crash.
Added the vol dbnest = yes with only home share active, still crash.

@rdmark
Copy link
Member

rdmark commented Jan 18, 2025

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 #1235 which makes me agree with NJRoadfan's assessment that the root cause is traces of nested netatalk volumes.

@rdmark rdmark marked this as a duplicate of #1235 Jan 18, 2025
@rdmark
Copy link
Member

rdmark commented Jan 18, 2025

@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: #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.

@NJRoadfan
Copy link
Contributor

NJRoadfan commented Jan 18, 2025

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.

@rdmark
Copy link
Member

rdmark commented Jan 18, 2025

I added a hint about rebuilding the CNID database to the error log message.

@pbobbenb
Copy link
Author

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.

@rdmark
Copy link
Member

rdmark commented Jan 19, 2025

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?

@pbobbenb
Copy link
Author

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

@pbobbenb
Copy link
Author

Tried the path = afp-data in homes and that works when opening the mounted home share.

@pbobbenb
Copy link
Author

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants