Menu

#665 Multiple users only one user get access

None
wont-fix
nobody
None
1
2023-04-11
2021-04-09
Tristan
No

I am trying to set up sharing with multiple users on a pi. It is not working when trying to log in with the second new user in MacOS (10.15.7 and older versions). It will always fail when you try logging in with the second user. Logging in with the pi user will work! Just not the second user.

If I add uams_randnum.so it works for some reason but not without it. And that option is described as legacy in your documentation.

I am using afpd 3.1.12 from the pi repo, using a new clean current rasberry pi images (Linux 5.10.17-v7+ #1403, Release date: March 4th 2021).


Clean install apt-get install netatalk

I added one user with the command sudo useradd Tristan and added that users group to the pi group with sudo usermod -a -G Tristan pi

Then creating the shared folder with

sudo mkdir -p /mnt/data/Shared
sudo chown Tristan:Tristan /mnt/data/Shared
sudo chmod 774 /mnt/data/Shared

and my config is

[Global]
uam list = uams_dhx.so , uams_dhx2.so
mimic model = MacPro

[Shared]
path = /mnt/data/Shared
valid users = @Tristan

[Home]
path = /home/pi
valid users = pi

Logging (failed with user Tristan, success with user pi)

Apr 09 16:10:00.312857 netatalk[1461] {netatalk.c:446} (note:Default): Netatalk AFP server starting
Apr 09 16:10:00.333179 netatalk[1461] {netatalk.c:516} (note:Default): Registered with Zeroconf
Apr 09 16:10:00.343003 cnid_metad[1463] {cnid_metad.c:509} (note:AFPDaemon): CNID Server listening on localhost:4700
Apr 09 16:10:03.697522 afpd[1462] {afp_config.c:198} (note:AFPDaemon): Netatalk AFP/TCP listening on 10.0.11.1:548
Apr 09 16:10:08.748827 afpd[1489] {auth.c:235} (note:AFPDaemon): Login by Tristan (AFP3.4)
Apr 09 16:10:42.247319 afpd[1489] {auth.c:804} (note:AFPDaemon): AFP logout by Tristan
Apr 09 16:10:42.251605 afpd[1489] {dsi_stream.c:504} (error:DSI): dsi_stream_read: len:0, unexpected EOF
Apr 09 16:10:42.251716 afpd[1489] {afp_dsi.c:517} (note:AFPDaemon): afp_over_dsi: client logged out, terminating DSI session
Apr 09 16:10:42.259548 afpd[1489] {afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 0.60 KB read, 0.44 KB written
Apr 09 16:10:46.353926 afpd[1498] {auth.c:235} (note:AFPDaemon): Login by Tristan (AFP3.4)
Apr 09 16:10:48.276985 afpd[1498] {auth.c:804} (note:AFPDaemon): AFP logout by Tristan
Apr 09 16:10:48.281964 afpd[1498] {dsi_stream.c:504} (error:DSI): dsi_stream_read: len:0, unexpected EOF
Apr 09 16:10:48.282194 afpd[1498] {afp_dsi.c:517} (note:AFPDaemon): afp_over_dsi: client logged out, terminating DSI session
Apr 09 16:10:48.290807 afpd[1498] {afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 0.59 KB read, 0.44 KB written
Apr 09 16:10:52.347434 afpd[1503] {auth.c:235} (note:AFPDaemon): Login by Tristan (AFP3.4)
Apr 09 16:30:20.686598 afpd[1503] {auth.c:804} (note:AFPDaemon): AFP logout by Tristan
Apr 09 16:30:20.690472 afpd[1503] {dsi_stream.c:504} (error:DSI): dsi_stream_read: len:0, unexpected EOF
Apr 09 16:30:20.690572 afpd[1503] {afp_dsi.c:517} (note:AFPDaemon): afp_over_dsi: client logged out, terminating DSI session
Apr 09 16:30:20.698307 afpd[1503] {afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 1.18 KB read, 1.02 KB written
Apr 09 16:30:23.296372 afpd[1722] {auth.c:235} (note:AFPDaemon): Login by pi (AFP3.4)

Discussion

  • Tristan

    Tristan - 2021-04-09

    Has it something to do with the user pi used in cnid_dbd???

       CGroup: /system.slice/netatalk.service
               ├─612 /usr/sbin/netatalk
               ├─622 /usr/sbin/afpd -d -F /etc/netatalk/afp.conf
               ├─623 /usr/sbin/cnid_metad -d -F /etc/netatalk/afp.conf
               ├─914 /usr/sbin/cnid_dbd -F /etc/netatalk/afp.conf -p /home/pi -t 7 -l 4 -u pi
               └─934 /usr/sbin/cnid_dbd -F /etc/netatalk/afp.conf -p /mnt/data/Shared -t 8 -l 4 -u pi
    
     
  • Daniel Markstedt

    I think this is a configuration issue. You should use the [Homes] section to define access to the home dirs. Also, why do you allow access to the group @Tristan rather than the user Tristan?

    Something like this should give you the behavior you want:

    [Global]
    uam list = uams_dhx.so uams_dhx2.so
    mimic model = MacPro

    [Homes]
    basedir regex = /home

    [Shared]
    path = /mnt/data/Shared
    valid users = Tristan

     
    • Tristan

      Tristan - 2023-04-11

      For background as well what I remembered.

      The config file was correct... (still using it on a spare x86 server on
      which I have not encountered this problems). probably added the @ with
      testing since shit didn't work. And the documentation (and google) misses
      some good real world examples. (there is a lot of guessing on google) I
      assure you it, didn't work for the single user also.

      Also does not explain why uams_randnum.so did make it work??? Does this
      option just do away with the whole users/group stuff?

      or why nothing is in the log except dsi_stream_read: len:0, unexpected EOF
      instead. Which tells me nothing since I am a user not a dev.

      What you expect (in the latter case with @ that group does not exists at
      least a warning) what is wrong.

      Didn't want to share home folders.. except explicitly the admin (pi) user.

      Anyway this is two years ago. I switched to debian 11 on x86 where I had
      no such problems. Didn't had to supply an uam list like on the pi. Just
      worked.

       
  • Daniel Markstedt

    • status: open --> wont-fix
    • Group: -->
     
  • Daniel Markstedt

    Thanks for providing the additional context! Yes randnum is a special case because it uses afppasswd for managing credentials in /usr/local/etc/afppasswd (by default) so it is not suprising that you saw different behaviors there.

    That exact dsi_stream_read error is very very common still today and is because of messy handling of timeouts I think.

    FYI in the upcoming netatalk release we introduce a cleaner way to share home dirs with specific users or groups, f.e.:

    [Homes]
    basedir regex = /home
    valid users = pi
    
     

Log in to post a comment.