Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kevindt]

This is an older thread, but it did not resolve the problem.  I tried to follow the instructions per the wiki and this thread without success till I realized that the problem is that I'm using a Mac.  Windows users would not have the same problem as Unix permissions are not in use then.

The fun_plug script downloads on the Mac with owner set to the mac username and only -rw-r--r-- permissions set (non-executable).

Use Mac terminal to set the permission to rwxrwxrwx

Code: [Select]

chmod 777 /Volumes/Volume_1/fun_plug
and change owner to root

Code: [Select]

chown root /Volumes/Volume_1/fun_plug  

and it worked perfectly on rebooting the NAS

Kevin.

[jamieburchell]

That's strange. Every file I've ever put on the NAS via Windows XP/Vista/7 ended up with 777 permissions and owned by the user (and group) I was logged in as. I don't see why that's not the case on a Mac? Don't they both use SMB?

[kevindt]

The downloaded file has permissions on the Mac of -rw-r--r-- with owner = mac user.

If that file is transferred as-is to the NAS via Finder, its permissions remain -rw-r--r-- with owner = nobody (usergroup 501).  Obviously the script won't run as non-executable.  Change to executable and now it works just fine.

(Whenever files are copied, Mac OS X uses the following protocol: the POSIX permission bits of the copy are always retained. In other words, if the original file is 0755, then the copy will be 0755; however, the POSIX owner will be changed to the currently connected user).

Kevin

[jamieburchell]

That might explain why lots of Mac users are having permission problems with their files stored on the NAS then.

[kevindt]

It probably is.  Without editing the permissions on the Mac before transferring them, the default permissions for files are 0644 (-rw-r--r--) and for directories are 0755 (drwxr-xr-x), and since Leopard they transfer intact, totally ignoring any masks or force create mode statements in /etc/samba/smb.conf.
(See http://discussions.apple.com/thread.jspa?messageID=7349655 for more detail).

/etc/samba.smb.conf

Code: [Select]


[global]
interfaces = egiga0
unix charset = UTF8
workgroup = workgroups
netbios name = dlink-09391A
server string = DNS-321
hosts allow =
hosts deny =
security = SHARE
encrypt passwords = yes
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
max xmit = 65535
create mask = 0777
directory mask  = 0777
force create mode = 0777
force directory mode = 0777
use sendfile =yes
disable spoolss = yes


[ web_page ]
comment = Enter Our Web Page Setting
path = /mnt/web_page
valid users =
read only = yes
guest ok = yes

[ Volume_1 ]
comment =
path = /mnt/HD_a2
valid users =
read only = no
guest ok = yes
oplocks = no
map archive = no

[ Volume_2 ]
comment =
path = /mnt/HD_b2
valid users =
read only = no
guest ok = yes
oplocks = no
map archive = no


Windows, on the other hand, properly respects the file and directory masks in the [global] section of /etc/samba/smb.conf on the NAS, which is why all your transfers from Windows to the NAS gain 0777 permissions.

Editing /etc/samba/smb.conf on the NAS to add:

Code: [Select]

unix extensions = off
to the [global] section, then restarting samba works, but does not survive a reboot.  I guess I need to make up a script to run on startup that will stop samba, copy a modifed smb.conf to /etc/samba/ and restart samba.

Kevin.

[kevindt]

Script to work around permissions problem with Mac after Fun_Plug is installed

Create this and save as /ffp/etc/fun_plug.local

Code: [Select]

#!/bin/sh

if [ ! -f /mnt/HD_a2/smb.conf.orig ]; then
   echo "Backup original /etc/samba/smb.conf"
   cp /etc/samba/smb.conf /mnt/HD_a2/smb.conf.orig
fi

if [ -f /mnt/HD_a2/smb.conf ]; then
   echo "Copy amended smb.conf to /etc/samba/"
   cp /mnt/HD_a2/smb.conf /etc/samba/smb.conf
   smb restart
fi

Then give it 0755 permissions

Code: [Select]

chmod 755 /ffp/etc/fun_plug.local
Run it once.  If not using ssh, reboot.  If using ssh use

Code: [Select]

sh /ffp/etc/fun_plug.local
That will copy the /etc/samba/smb.conf to /mnt/HD_a2/smb.conf.orig

If running via ssh it will look like:

Code: [Select]

root@dlink-09391A:~# sh /ffp/etc/fun_plug.local
Backup original /etc/samba/smb.conf
root@dlink-09391A:~#
Edit it to add the line

Code: [Select]

unix extensions = off
to the [global] section

Code: [Select]

[global]
interfaces = egiga0
unix charset = UTF8
workgroup = workgroups
netbios name = dlink-09391A
server string = DNS-321
hosts allow =
hosts deny =
security = SHARE
encrypt passwords = yes
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
max xmit = 65535
# <------Added here
unix  extensions = off
#  
create mask = 0777
directory mask  = 0777
force create mode = 0777
force directory mode = 0777
use sendfile =yes
disable spoolss = yes


[ web_page ]
comment = Enter Our Web Page Setting
path = /mnt/web_page
valid users =
read only = yes
guest ok = yes

[ Volume_1 ]
comment =
path = /mnt/HD_a2
valid users =
read only = no
guest ok = yes
oplocks = no
map archive = no

[ Volume_2 ]
comment =
path = /mnt/HD_b2
valid users =
read only = no
guest ok = yes
oplocks = no
map archive = no
and save it as /mnt/HD_a2/smb.conf.

Either re-run the script via ssh or reboot a second time.

If running with ssh it should look like:

Code: [Select]

root@dlink-09391A:~# sh /ffp/etc/fun_plug.local
Copy amended smb.conf to /etc/samba/
$Shutting down SMB services:
$Shutting down NMB services:
$Starting SMB services:
$Starting NMB services:
root@dlink-09391A:~#  
Now Mac files are all saved with 0777 permissions too.  Once the amended smb.conf is present and the script is present, it will auto-load the amended smb.conf on every reboot.

[jamieburchell]

It probably is.  Without editing the permissions on the Mac before transferring them, the default permissions for files are 0644 (-rw-r--r--) and for directories are 0755 (drwxr-xr-x), and since Leopard they transfer intact, totally ignoring any masks or force create mode statements in /etc/samba/smb.conf.

That's very interesting. I didn't realise that at all. I had thought that the NAS itself handled file permissions, regardless of where the files originated from. Certainly may help the guys in the 323 forum too, who have had file access permission issues on certain files, seeminly at random.
Assuming the 323/321 are supposed to be Mac compatible, that's a bug for D-Link?

[kevindt]

I'm not sure it is, but searching this forum briefly seems to suggest it might have started to be an issue when people upgraded to firmware 1.03 - and if that is really so, yes its a bug!

Just thinking.  If fun_plug is NOT installed, I wonder if you re-named the same little script fun_plug with executable permissions set and placed it in the root of the first hard drive, would it patch the DNS the same way too?  Guess it depends at which stage in boot the fun_plug hook is at 

I'm not going to uninstall fun_plug to try it out, but I do have a couple more of these boxes on order (they are currently significantly discounted at TD plus D-Link has a $20 rebate on the 321 ($40 on the 323) per box on up to 2 boxes through 11/30).  I might try it on one when it arrives.  It can't damage anything, at worst I'd have to delete it from the drive to be back to baseline.

Kevin

[jamieburchell]

You don't need the full Fonz Fun Plug (ffp) installed if you just want your script to run. Simply put it in fun_plug with executable permission on the root of Volume_1. This is the file the DNS looks for and what made FFP possible.

[kevindt]

That's what I thought, but was waiting for an unmodded DNS-321 to arrive to check it!  Thanks for saving the time 

Kevin

[kevindt]

Without the change to smb.conf, this gets more interesting the more you play.

Mac and Ubuntu Linux behave quite differently.

Copy a file from Ubuntu (10.04 LTS live CD) using Nautilus to NAS -> permissions change to 0777 like Windows
Copy it back to Ubuntu and they return to prior default (ubuntu:ubuntu 0755)

Copy a file from Mac desktop to samba-mounted NAS using Finder -> Mac permissions preserved on NAS
Copy it back and there is no change.

Copy a file from Mac Desktop to samba-mounted NAS by command-line cp (no flags) -> group and others become 0 (0666 or 0644 -> 0600, 0755 -> 0700).  

Move a file from Mac Desktop to samba-mounted NAS by command-line mv (no flags) -> permissions change to 0777 and remain so if copied back.

I haven't tried moving to/from a folder with different permissions/umask to see what is happening there, and whether it is inheritance from parent folders that is interfering.

Kevin.

[jamieburchell]

So how have you been transferring the files from the Mac to cause the issue?

[kevindt]

Using Finder (i.e. by GUI drag-drop).

It has not been problematic if you are only using it to store data for use purely with the Mac.  The problem comes with how the inherited permissions from the Mac interfere with access and execution on devices using another OS - including the NAS itself.

If permissions are all converted to 0777 for data and programs stored on the NAS Volumes, as they obviously intended to do based on the smb.conf in the NAS firmware, that should reduce many of the problems across operating systems.  However, it does mean being very careful if using FFP.  If transfers come via Samba from Windows or Linux (or Mac, if smb.conf is modified by the script above), all files become executable - even data.  Of course, that is not a problem if the device is used just for storage as intended.

[kevindt]

And one more observation.

Transferring (copying) files via FTP (using FireFTP, logged into the NAS FTP as superuser) from the Mac to the NAS converts them all to 0777 permissions on the NAS!  Pulling them back gives them 0644 permissions regardless of original permissions.

Kevin.

[jamieburchell]

Just out of interest, are you running the latest firmware version on your NAS, and did you do a factory reset after upgrading? Wondering if it would change the behaviour.