Shares permissions

I have recently purchased a My Cloud Mirror to use it as an afp storage I could access from either my internal network or from outside. After going through the setup (not the easiest on earth) what I found out is that my shares (let’s call them WD_UH and WD_UHSSD), which are NOT public, have their permissions set to 777 (rwxrwxrwx). Obviously, this is not something you want to allow on a NAS which is on the public internet.

I’ve tried to manually change the permissions, by ssh connection to the device, and that works, but every new file uploaded to the afp connected disks, still gets the 777 permissions. Even editing the /etc/netatalk/afp.conf file and setting the file and directory permissions to 770 (for example) doesn’t work, since afp.conf gets re-written every time MyCloud gets rebooted.

Has anyone managed to solve this permissions issue, and if so, how?

Help would be very much appreciated.

(P.S.: I am using Mac computers to access MyCloud, and I can mount the shares I have defined, and copy files to them, but the permissions are all messed up. All other services, smb, cloud access, Time Machine backups etc are all off).


Does your user have “Full Access” to the shares?

If so, try to create another shared folder to see it has the same permission.

What I have found so far, is that you can change the share permissions and ownership, using regular linux commands. These remain intact after a reboot. However, /etcnetatalk/afp.conf gets over-written, but (and that’s a big but) you can edit it after the system has rebooted and before you mount any share on your PC or Mac, and then files uploaded to the shares get the proper permissions you specified.

So my thought, is to save a modified afp.conf somewhere (probably in the Public share) and then copy it to /etc/netatalk/afp.conf when the system is done bootingg up. I just have to figure out how to do the copying!

For those who will read about this issue later, I have managed to temporarily solve this problem, in a very unprofessional way, not thanks to WD faulty afp implementation.

For those interested, after all the preliminary work is done, i.e. define the shares and the users (with password) that I want to access those shares, I copied the /etc/netatalk/afp.conf file somewhere on one of my shares (after I have fixed their permissions). I then edited the copied version of afp.conf to set file perm to 700 and directory per to 700. The modified afp.conf has to be copied to /etc/netatalk BEFORE you mount your shares to your computer. After you do that, the files you upload to your shares will get the permissions you want (700). However, this is not a permanent change. In other words, every time your NAS is rebooted, you have to copy the modified afp.conf to /etc/netatalk, in order for your uploaded files to have 700 instead of 777 permissions.

What an idiotic approach, for a NAS device which can be mounted on the open internet!!!

A very BIG thanks, to dswv42 for his Guide shown above! I couldn’t have made it, without you, buddy!

OK, this thread is two years old, and mine to start with, but I need help!!!

I have decided to resurrect my WD device, to act as an afp backup, again. And of course, I am facing this old problem, of unsecure permissions. Changing the afp.conf file, solves the problem, but I haven’t found a way to restart netatalk, except by kill -HUP netatalk process number. Obviously, that doesn’t help much. I tried service netatalk restart, didn’t work, I tried systemctl restart netatalk, didn’t work. Any idea how to restart netatalk via a shell command?!?!!?

It’s an old My Cloud Mirror (Part number WDBZVM0040JWT-20) with firmware 2.11.178.

Please help!!!


The reason I am digging thought this, also, is that upon reboot my USB HDD keeps getting its share name changed. To add to that initially I set it up as public until I finish setting it up.
The external HDD has to partition/volumes. One keeps the changes, the other one didn’t. My examination of the issue led me to “/etc/netatalk”.
Here is what I am thinking, after looking as the process.

21334 root 2592 S grep netatalk
28090 root 5728 S /usr/sbin/netatalk
28093 root 7392 S /usr/sbin/afpd -d -F /etc/netatalk/afp.conf
28094 root 5760 S /usr/sbin/cnid_metad -d -F /etc/netatalk/afp.conf

First, get the process PID. In this case “28090”, kill it, check if other related processes are closed, if not killed them too. Run the command of the original process check if the additional processes are running too. Check that the file was not overwritten.
I will be looking into where the backup comes from and who is overwriting the config file. Let me know if you are still interested, in me sharing any additional findings.