Won't save icon position / view format at root level.

[ByteKnight6]

I can't get netatalk on the PiSCSI to save icon location / view format at the root level. It works with my older version of netatalk in A2SERVER, but not the newer version. What's interesting is that it saves the icon location / view format at the subdirectory level. https://youtu.be/78BOSka-2r0

[ByteKnight6]

Ok, so I found a workaround. If you create a folder (with 777 permissions) in /home/pi/afpshare which contains all the files/folders you want to share, and point /etc/netatalk/AppleVolumes.default to that folder then it saves icon positions / view format at the root folder level.

[rdmark]

@ByteKnight6 So your workaround is to create a subfolder under /home/pi/afpshare such as /home/pi/afpshare/foobar and then use that as the shared volume?

May you share the output of ls -al for both dirs so that we can confirm the permissions flags for both?

[rdmark]

FWIW I tried to reproduce with netatalk 2.x code (the latest HEAD) but I couldn't see it in my environment. I put a dir under /home/username and set the permissions to 2775 (just like the piscsi script does it) and then followed the steps. However at step 2 the changes to the Finder view settings were retained.

Does it happen specifically when you log in as Guest at step two, or does it happen also when you authenticate both times?

[ByteKnight6]

May you share the output of ls -al for both dirs so that we can confirm the permissions flags for both?

root@CQFileServer:/home/pi/afpshare# ls -al total 12 drwxrwxrwx 3 pi pi 4096 Sep 10 16:39 . drwxr-xr-x 11 pi pi 4096 Sep 8 21:15 .. drwxrwxrwx 20 root root 4096 Sep 10 17:07 ApplePi root@CQFileServer:/home/pi/afpshare# cd ApplePi root@CQFileServer:/home/pi/afpshare/ApplePi# ls -al total 132 drwxrwxrwx 20 root root 4096 Sep 10 17:07 . drwxrwxrwx 3 pi pi 4096 Sep 10 16:39 .. drwxrwxrwx 2 root pi 4096 Sep 10 17:24 .AppleDB drwxrwxrwx 5 root pi 4096 Sep 10 17:03 .AppleDesktop drwxrwxrwx 2 nobody nogroup 4096 Sep 10 15:35 .AppleDouble drwxrwsrwx 18 nobody nogroup 4096 Sep 10 15:34 'Apple IIgs' drwxr-sr-x 3 nobody nogroup 4096 Sep 9 17:05 'BBS Software' drwxrwsrwx 3 nobody nogroup 4096 Aug 30 18:49 'B&W Mac Apps' drwxr-sr-x 3 nobody nogroup 4096 Sep 12 2021 'B&W Mac Games' drwxrwsrwx 3 nobody nogroup 4096 Dec 30 2021 'CD Compilations' -rw-r--r-- 1 root nogroup 6148 Sep 10 15:33 .DS_Store drwxrwsrwx 10 nobody nogroup 4096 Dec 18 2020 'Game Text Files ' drwxrwsrwx 3 nobody nogroup 4096 Nov 20 2020 'Hypercard Stacks' -rwxrwxrwx 1 nobody nogroup 0 Feb 1 2022 'Icon'$'\r' drwxrwsrwx 3 nobody nogroup 4096 Dec 20 2020 'Inside Mac Games • 1993-1995' drwxrwsrwx 4 nobody nogroup 4096 Aug 29 12:43 'I was here!' drwxrwsrwx 3 nobody nogroup 4096 Jan 15 2022 'Mac Network Games' drwxrwsrwx 3 nobody nogroup 4096 Sep 9 17:23 'Mac Terminal' drwxrwsr-x 3 root pi 4096 Jan 31 2022 'Network Trash Folder' drwxr-sr-x 3 nobody nogroup 4096 Sep 10 17:03 'New Mac Releases' drwxrwsr-x 3 root pi 4096 Jan 31 2022 'Temporary Items' drwxrwsrwx 11 nobody nogroup 4096 Jan 23 2022 Uploads

[ByteKnight6]

FWIW I tried to reproduce with netatalk 2.x code (the latest HEAD) but I couldn't see it in my environment. I put a dir under /home/username and set the permissions to 2775 (just like the piscsi script does it) and then followed the steps. However at step 2 the changes to the Finder view settings were retained.

Does it happen specifically when you log in as Guest at step two, or does it happen also when you authenticate both times?

I only tried logging on as Guest.

[rdmark]

root@CQFileServer:/home/pi/afpshare# ls -al

Can you please do the same from within the /home/pi dir? What I want to see is the permissions on the afpshare dir. Please feel free to filter out any private info. :)

I only tried logging on as Guest.

The Guest user is actually accessing as the nobody user on *nix, so my theory is that nobody didn't have write permissions on the relevant AppleDouble metadata in the root of the shared volume. The default permissions flags that my piscsi script sets up is 2775, which means write privileges only for the pi user.

With this in mind, I'm thinking of moving the default shared volume configuration out of /home/pi and into /srv/netatalk instead. The home dirs have some unique permissions that it seems afpd gets confused by...

[ByteKnight6]

Can you please do the same from within the /home/pi dir? What I want to see is the permissions on the afpshare dir. Please feel free to filter out any private info. :)

root@CQFileServer:/home/pi# ls -al total 76 drwxr-xr-x 11 pi pi 4096 Sep 8 21:15 . drwxr-xr-x 3 root root 4096 Jan 27 2022 .. drwxrwxrwx 3 pi pi 4096 Sep 10 16:39 afpshare -rw------- 1 pi pi 5381 Sep 9 18:30 .bash_history -rw-r--r-- 1 pi pi 220 Jan 27 2022 .bash_logout -rw-r--r-- 1 pi pi 3523 Jan 27 2022 .bashrc drwxrwxrwx 3 pi pi 4096 Sep 8 21:17 .config drwx------ 2 pi pi 4096 Jan 31 2022 .cups drwx------ 3 pi pi 4096 Jan 30 2022 .gnupg drwxrwxrwx 3 pi pi 4096 Sep 9 20:57 images drwxr-xr-x 4 pi pi 4096 Feb 1 2022 macproxy-21.12.3 -rw-r--r-- 1 pi pi 4243 Feb 1 2022 macproxy-21.12.3.tar.gz drwxr-xr-x 15 pi pi 4096 Jan 31 2022 Netatalk-2.x-netatalk-2-220101 drwxr-xr-x 12 pi pi 4096 Sep 8 21:19 piscsi -rw-r--r-- 1 pi pi 807 Jan 27 2022 .profile drwx------ 2 pi pi 4096 Jul 19 2022 .ssh -rw-r--r-- 1 pi pi 328 Sep 8 21:19 .wget-hsts

[rdmark]

Thanks! Well, that only tells us that the flags are the permissive 777 writable for everyone, so the issue is a bit of a mystery.

[ppuskari]

I've been spending a LOT of time attempting to get this package installed with a repeatable process that gets us the ability to login with multiple users for gs and //e booting with proper preference saving as well as papd printer support though cups and avahi bonjour etc. and connectivity to the share from Macs and PC and linux with file and window positioning saves etc across all the shares.

What I have found is that it seems that the logged in user when creating new files and folders will do so under it's own id. so if user a2boot creates a folder it will get user:group a2boot:a2boot with whatever perms we have set on the volume (perms seem to work) on the AppleVolumes.default definitions.

if I log in with gsboot then it will create new files and folders with gsboot:gsboot in whatever file share folder it is selected to map to. So if A2Shares is being modified by a2boot logged in and creates some files, then if gsboot logs into that same share it can create new folders with gsboot:gsboot just fine and save window positions from the mac side. BUT any folder that was already present and created by a2boot....well it can open and add new files and modify files etc just fine and even delete them, but the mac can NOT save window files to any of those folders.....

`So my temp fix ended up going and doing a "sudo chown -R root:users EverySharedFolder" so this put root:user on everything and now I can log in with any user and touch any folder/file and everything is just great. UNTIL I create a folder with the user and it hard sets it to a2boot:a2boot or gsboot:gsboot which then makes that folder non windows position and view type savable to other users until I rechown the trees.

Is there a way in netatalk 2.2.x to force all the owner of all new files/folders to root? the group doesn't seem to matter too much but the USER definitely works. I even added all the users to the pi group and that didn't help either. Seems like for all the users to save against the folders they need to be root owned.

Any ideas?

[rdmark]

Have you tried setting the suid/sgid or sticky permission bits on the entire shared volume? See https://www.redhat.com/sysadmin/suid-sgid-sticky-bit

I'm not sure if this will make difference but I'm curious what your testing will show. The netatalk permissions scheme is still a bit of a blackbox to me.

Also, it would be great to know if upstream netatalk 2.2.10 behaves exactly the same. I did a chunk of cleanup and refactoring in 2.x that might have impacted this behavior.

[ppuskari]

Thanks for the hint and normally I would think that would work by setting up the sgid on the directory so that the new files end up in the group. I tried that and the function does its job and I can set the group to any group. Even including the group root! I tried with 3 of the ids I created and the perms on the folders like this

pi@piscsi:~/MacFiles $ ls -al total 72 drwxrwxrwx 10 root nogroup 4096 Sep 15 02:35 . drwxr-xr-x 15 pi pi 4096 Sep 15 01:14 .. -rwxrwxrwx 1 root nogroup 19329 Jan 3 1976 Apple.Bowl drwxrwxrwx 2 root nogroup 4096 Sep 14 17:11 .AppleDB drwxrwxrwx 11 root nogroup 4096 Sep 14 23:59 .AppleDesktop drwxrwxrwx 2 root nogroup 4096 Sep 15 02:14 .AppleDouble -rwxrwxrwx 1 root nogroup 10240 Dec 13 1976 BASIC.System drwxrwxrwx 4 root nogroup 4096 Sep 14 11:25 'Network Trash Folder' drwxrwxrwx 3 root nogroup 4096 Sep 18 2023 'SCSI Director 3.1' drwxrwxrwx 3 root nogroup 4096 Sep 14 17:14 'Temporary Items' drwxrwxrwx 3 root nogroup 4096 Sep 15 02:09 'untitled folder' drwxrwxrwx 7 root nogroup 4096 Sep 15 02:18 'untitled folder 2' pi@piscsi:~/MacFiles $

That one shows the test I did with nogroup as group as well. The group doesn't make a difference. I tried with user root and the current netatalk userid and those are the ONLY two that work even with wide open perms. In order to save files layouts etc on folders created by NOT you, it must be root and any group will do.

Something feels like afpd or atalkd? is hard setting that file owner based on who you logged in with.. I wonder if there is a way we can find where that is set and just hardcode it to root. Which is odd but would work. Or perhaps find the area that maybe obeys group perms????

I'm tempted to find a notify solution that handles file creation and then brute forces the chown to root:nogroup. Not a great solution but pragmatic at this point.

Thanks!

[ppuskari]

Just got piscsi latest update running now with 4 users that all can access the files and save window positions in MacOS 7.6.1 at least, with cups and auto printer setup, and GS netbooting properly working. there is still an issue with reading a file if you select net printer from the control panel where it can find or build the printing preferences I think but it still seems to properly get set for use for printing... Doesn't happen on AS3.0 proper however. to fix the ownership stuff I am currently running with perm:0777 upriv and ea:ad on the shares seems to be okay. BUT I prep each share with sudo chown -R root:users

I have all my appleshare users added to the users group as well.

Then in my case for 4 shares I have 4 background shell scripts running and will put them in to start at launch and send output to null tomorrow... Here is the script I'm using against each share using notifier

https://gist.github.com/gravelld/7b3fdec08a5c2c74258fca29b1e18bb9

[rdmark]

Perhaps I misunderstand the original issue, but maybe it's by design that window positions aren't shared between users of the volume? Wouldn't it be startling if someone else's changing of icon or window settings takes effect when you mount a volume you used before?

In any case the fact that folders created by one user can't be written to by other users is definitely unwanted though. This one occurs consistently between Apple II clients and Mac clients?

Do you mind sharing your config files so that I can attempt to reproduce your scenarios?

[ppuskari]

Most definitely. I’ll get the configs together in a package for you. It’s been working great! Yeah the person only share makes sense. But on the fully shared volumes. Hmm. I wonder how that is done regularly? I will have to sign j to the AppleShare 3.0 server on a shared file share from two os7 machines and see what happens. It appears the stuff is stored on the file share in an Apple double file though from watching the creator chowns that take care of things for me on that now.

On a plus side even gsport emulator NetBoot is working now.

Sent from my iPhone

On Sep 15, 2023, at 12:23 PM, Daniel Markstedt @.***> wrote:



Perhaps I misunderstand the original issue, but maybe it's by design that window positions aren't shared between users of the volume? Wouldn't it be startling if someone else's changing of icon or window settings takes effect when you mount a volume you used before?

In any case the fact that folders created by one user can't be written to by other users is definitely unwanted though. This one occurs consistently between Apple II clients and Mac clients?

Do you mind sharing your config files so that I can attempt to reproduce your scenarios?

— Reply to this email directly, view it on GitHubhttps://github.com/rdmark/netatalk-2.x/issues/42#issuecomment-1721610432, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAIMVUCKWCV3XOLI4FC6E4TX2SFH3ANCNFSM6AAAAAA4SMOLJQ. You are receiving this because you commented.Message ID: @.***>