Synology DSM Permissions Problem

[Analog Kid]

Any idea how to fix a problem where the files on my NAS show:

• user "(unknown)" with read/write privileges
• group "(unknown)" with read only privileges
• everyone with no access

Looking from the terminal, these directories show my username and group "staff" as owners.

I'm unable to add permissions or change the file owner through Finder or the command line.

As background:

I used to use a Drobo for my bulk storage needs, and finally got fed up with their lack of support, junked it, and have been trying to adapt to the NAS world.

I have a DS1515+, running DSM 6.1.

I've copied my files from the Drobo to the Synology, including my iTunes library and I've been having a few headaches ever since (refusing to transfer files from an iPad, my podcasts have gone wonky, etc). Looking into it I'm seeing my files all have these weird permissions issues.

Anybody have any experience with this?

 

[steve62388]

Have you set up users and their permissions on your Diskstation correctly? I'm not sure it's the best idea to be trying to change them through Terminal, go through DSM instead.

I'm not familiar with Drobo, but it wouldn't surprise me if that and your Diskstation don't support identical file permissions.

 

[arggg14]

delete

 

[Analog Kid]

Have you set up users and their permissions on your Diskstation correctly? I'm not sure it's the best idea to be trying to change them through Terminal, go through DSM instead.

I'm not familiar with Drobo, but it wouldn't surprise me if that and your Diskstation don't support identical file permissions.

Thanks. I've done the best I can to set permissions up correctly. I went and repeated the process and things are going a little bit smoother, but I can't see what, if anything, has changed. I'm also finding my iTunes library is pretty fubar, which might be contributing to the problem-- but I'm not sure of what's cause and what's effect.

Is it normal to have users and groups listed as "(unknown)"? When I make AFP connections to other servers, the permissions work as expected...

 

[boast]

How was the transfer done? User IDs and Group IDs between macOS and Synology will not match/exist.

Are you logging into the share (smb or afp) when mounting it? That login should be as a synology user and the files written should appear as that user.

 

[Analog Kid]

How was the transfer done? User IDs and Group IDs between macOS and Synology will not match/exist.

Are you logging into the share (smb or afp) when mounting it? That login should be as a synology user and the files written should appear as that user.

Did the transfer via Finder with a Mac in the middle.

I'm realizing that the other Synology system I'd worked with was actually mounting a sparse bundle, which is probably why I remember seeing all of the names and permissions in the traditional way. I may go that way here too.

I like the NAS as an appliance, but it's little stuff like this that makes the experience feel awkward.

Presumably I could get everything to play nice if I set up a directory service?

 

[priitv8]

From my experience (not with a Synology but with a D-Link NAS), what you are attempting, may actually never happen.
Whenever I connect to mine via AFP protocol, I get similar results as you do. When I connect via SMB, I see simply "You have custom access".
The trick here is, that the NAS itself uses it's own filesystemand rights management inside its own OS. This in general is not macOS or it's native filesystem (except for macOS server fileshares). Mine for example runs on Embedded-Linux kernel and ext3 filesystem.
Everything, you see on macOS side, is virtual and presented by local network filesystem driver. And from the above, I can see that AFP and SMB drivers present both functionality and permissions differently. (as a side note: on Sierra, SMB mount to my NAS works much better and consistent than AFP. AFP implementation inside my NAS is also very old as the device has not seen firmware updates since 2013).
Real access permissions will be evaluated and enforced on the OS inside NAS anyway. They will be translated to permissions on guest side by network filesystem driver.
Actually, macOS server's file sharing does the mapping 1:1. So the permissions look quite the same on guest OS, except that the owner is (unknown).
NAS works very differently from DAS in this respect.
How the permissions are handled, you can read in Apple's Developer documentation on network file systems.
I personally am fed up with my D-Link and on the way to DAS, that I intend to share via macOS Server, running on Mac Mini.

 

[Analog Kid]

From my experience (not with a Synology but with a D-Link NAS), what you are attempting, may actually never happen.
Whenever I connect to mine via AFP protocol, I get similar results as you do. When I connect via SMB, I see simply "You have custom access".
The trick here is, that the NAS itself uses it's own filesystemand rights management inside its own OS. This in general is not macOS or it's native filesystem (except for macOS server fileshares). Mine for example runs on Embedded-Linux kernel and ext3 filesystem.
Everything, you see on macOS side, is virtual and presented by local network filesystem driver. And from the above, I can see that AFP and SMB drivers present both functionality and permissions differently. (as a side note: on Sierra, SMB mount to my NAS works much better and consistent than AFP. AFP implementation inside my NAS is also very old as the device has not seen firmware updates since 2013).
Real access permissions will be evaluated and enforced on the OS inside NAS anyway. They will be translated to permissions on guest side by network filesystem driver.
Actually, macOS server's file sharing does the mapping 1:1. So the permissions look quite the same on guest OS, except that the owner is (unknown).
NAS works very differently from DAS in this respect.
How the permissions are handled, you can read in Apple's Developer documentation on network file systems.
I personally am fed up with my D-Link and on the way to DAS, that I intend to share via macOS Server, running on Mac Mini.

Any idea which DAS you're going to pick? I went with the Synology NAS because I couldn't find a good DAS alternative to Drobo and I'd had enough of Drobo's lack of support and transparency. One thing that's important to me is that I can mix and match different drive sizes so that I don't need to buy a full new set of drives when I want to expand.

In general though, I prefer the DAS approach.

I think the problem is that the user and group IDs are numeric and assigned sequentially, so if they don't match on both devices the result comes up "unknown". I'd hoped there was a translation that happened across the network interface, but in thinking it over that's nearly impossible. Sure it should be able to draw the connection between my local ID and the NAS account I've logged in to, but there's no way the system can know how the other users on each system relate.

Thanks for the document you sent. I'd never seen that before, and it's quite interesting. It appears to suggest that ACLs can bridge between different sets of user IDs on different file systems in AFP 3.0. I'm not sure what DSM 6.1 supports.

There's also a Directory Service available for the Synology (or I could install Sever on my Mac) that I think would solve the problem. I'd have to look at what it would take to fix permissions on all of my existing files.

 

[priitv8]

To be frank, it will be Drobo 5C
Should arrive next week. I have no previous experience with them, so I do not have any presuppositions about their support or transparency.
Then again, that can be said about D-Link as well. Or more precisely - I never needed theirs.
But I hear from other people, that their box has been rock solid or that DroboCare really replaced the MoBo with minimum hassle. What experiences did you make?

What kind of problem do you experience that makes you look for a fix to permissions?
My D-Link at least enforces the set rights for users I have created on it's user management system.
It has had occasional hiccups, but for the most part, when a user has read-only access to a share, (s)he will not be able to delete or write files to it. Neither via command-line nor Finder. Despite how the permissions look on the guest macOS (I have no windows or linux machines around).
What I call hiccups are the opposite situations - sometimes I myself am unable to delete or rename a file, despite having full R/W access to network share. I then have to do it in the NAS's native file manager via web-browser.

I also have to admit, my permissions hiccups may be caused by myself, because fairly soon after having it up and running I decided to "jailbreak" it by installing the fun_plug.

 

[Analog Kid]

To be frank, it will be Drobo 5C
Should arrive next week. I have no previous experience with them, so I do not have any presuppositions about their support or transparency.
Then again, that can be said about D-Link as well. Or more precisely - I never needed theirs.
But I hear from other people, that their box has been rock solid or that DroboCare really replaced the MoBo with minimum hassle. What experiences did you make?

I've got some experience with Drobo S and Drobo 5D-- I'm using them for personal use, not corporate, so that makes a bit of a difference in how I think about support issues. Both have been reasonably reliable, though the S was going through an inordinate number of failures and corruption issues for a while. I replaced the power brick and that seemed to help. The S is dog slow, but the D seems to have improved on that significantly. I'm assuming the 5C is based on the 5D architecture, just with a USB C interface.

My issues were really with support-- they try really hard to avoid it. You must be registered to get access to much of anything (including their knowledge base, if memory serves) and if your support period expires they won't answer the simplest of questions.

For example: I wanted to switch my S from single drive redundancy to dual drive. To do that I needed to boost the capacity enough that I could sacrifice a drive to use for parity. Drobo has a maximum volume size, and if you exceed that size it automatically creates a second volume-- so as I was adding capacity, I tripped the limit and another volume was created that can never be removed. I flipped over to dual drive redundancy, the overall system capacity fell back under the single volume limit, but I was then condemned for the rest of eternity to have to tell OS X to ignore the phantom volume.

I asked support if there was a way to fix this, which I think was a pretty simple yes or no questions, and their answer was "your support period has expired".

Add to that the fact they give no indication of what their storage format is, so I started getting a little uncomfortable relying on it, and then they encrypt their log files so you can't get any sense of what the system health is except the green-yellow-red LEDs.

And then there's the fact that you set the maximum volume size up front (up to the limit I mentioned), and it lies to Finder ever after saying that there's more space on the drive than there is. I never had a problem with that because I kept a careful eye on it, but it feels like that could lead to Bad Things.

In the end though, it was the fact that I'd spent a couple thousand dollars on Drobo hardware and support gave me the "what have you done for us lately" treatment that finally tipped the scale for me.

What kind of problem do you experience that makes you look for a fix to permissions?
My D-Link at least enforces the set rights for users I have created on it's user management system.
It has had occasional hiccups, but for the most part, when a user has read-only access to a share, (s)he will not be able to delete or write files to it. Neither via command-line nor Finder. Despite how the permissions look on the guest macOS (I have no windows or linux machines around).
What I call hiccups are the opposite situations - sometimes I myself am unable to delete or rename a file, despite having full R/W access to network share. I then have to do it in the NAS's native file manager via web-browser.

I also have to admit, my permissions hiccups may be caused by myself, because fairly soon after having it up and running I decided to "jailbreak" it by installing the fun_plug.

The problems I've been having with the NAS have been permissions problems around my iTunes library-- can't transfer data off an iPad, store downloads would sometimes get blocked, etc. I seem to have corrected it in the short term-- but I'm not sure how... I've been trying a variety of different things through different interfaces and I guess one worked.

 

[ciimoc]

Any idea how to fix a problem where the files on my NAS show:

• user "(unknown)" with read/write privileges
• group "(unknown)" with read only privileges
• everyone with no access

Looking from the terminal, these directories show my username and group "staff" as owners.

I'm unable to add permissions or change the file owner through Finder or the command line.

As background:

I used to use a Drobo for my bulk storage needs, and finally got fed up with their lack of support, junked it, and have been trying to adapt to the NAS world.

I have a DS1515+, running DSM 6.1.

I've copied my files from the Drobo to the Synology, including my iTunes library and I've been having a few headaches ever since (refusing to transfer files from an iPad, my podcasts have gone wonky, etc). Looking into it I'm seeing my files all have these weird permissions issues.

Anybody have any experience with this?

I had same problem when creating the files or folders on afp, problem solved if connected to server via smb.
Turns out as pointed in this article https://www.synology.com/en-us/knowledgebase/DSM/help/DSM/AdminCenter/file_winmacnfs_mac if you check under advanced permissions if you activate the option of Write Unix default permissions it will give you problems when using other protocols like SMB.

Advanced Settings
Apply default UNIX permissions:
Enabling this option applies the default UNIX permissions when uploading or creating files and folders. Applied permissions are the same as permissions applied by the UNIX command umask. When this option is enabled, UNIX permissions are 644 for files and 755 for folders. When this option is disabled, UNIX permissions are 666 for files and 777 for folders. The default umask value is 022.

Note:
Enabling this option might cause inconsistent permission issues between different protocols. To avoid inconsistencies, we suggest leaving this option disabled.