I’m writing to you after hours of searches without success. Here is my problem.
I have a brand new DS916+
-> NFS activated
-> Shared Folder created
-> NFS Permission rw, no mapping, sys, all checked
-> A “pi” account with R/W permissions has access to the Shared Folder
The disk is mounted like below in /etc/fstab 192.168.1.121:/volume1/Family /mnt/nas nfs noauto,x-systemd.automount,noatime,soft 0 0
After a restart, everything is up and running.
With nano and the default “pi” account, I can read and write files.
But this local “pi” account is launching my Deluge application and this application have an access denied when trying to write on the NAS…
Any ideas why?
Is it because an account pi exist on the NAS?
I change umask to 000 on Deluge to test also, no changes.
I think you have
go to your Sysnology Admin page something like NAS IP :5000
then open the application flie server
go to your directory
right click proprieties
and in the new box
open permission
and you can see it
“double head” for groups
and you can modify a lot of things with this interface.
You’ve the buttom “Create” to add users or groups, and “modify” to change.
But it’ isn’t a good idea to change a lot of things in the same time.
Try the proposition from Tom, and write down all changes that you made.
You can also enable the synology journal option, but when you have never do it, it’s better to documente manually your
changes
EDIt: And backup your directory if you have real live data into.
I found everyone, restarted everything and it seems to work but I really not want to keep “everyone” able to write on my NAS…
Is there any way to get all incoming and failed request on the NAS side?
Sure, but I’ve never try it. Take a look to (in french) centre des journaux.
And you can also connect with ssh NAS IP to your NAS,
admin/password
and if you need root rights you can take it with sudo-i
and admin password.
There you can found (sometime ask google for found it, Synology make his own potage) all linux logs
But be care full, if you have a fresh NAS without data, play with it, you can make in the worst case a firmware reset, otherwise…
Hi. Did you read my thread about using NFS with Synology? As long as you don’t enable NFS v4 support, you shouldn’t have too many problems, once you’ve figured out how the permissions work.
A little background info, since there seems some confusion about various concepts.
NFSv3 does not authenticate users, it authenticates machines, based on their IP address. If the client’s IP is allowed access, the client will be able to mount the remote drive to a local folder. You can verify this on the client using the “df” or “mount” commands. (fstab only contains instructions on how to mount something, not whether the mount succeeded or not)
Whether or not a user can write to a mounted NFS share is solely determined by the underlying file system. Linux file systems do not care about user names, however. They rely on the numerical UID of the users and groups trying to perform an action. So if the “pi” account on your NAS has a different UID than the “pi” account on your client, you will not be able to do much.
The UID can be checked with the “id” command and should give you something like:
uid=1023(pi) gid=100(users) groups=100(users),101(media)
So if the UID for the pi user is different on both machines, you will get denied access to the file or directory you are trying to open.
In order to solve this, you could create a user on the NAS with the same UID as the “pi” user on the client and give access to the shared files to that user.
Furthermore, the umask only affects what permissions a newly created file gets, but has no influence on any existing files you are trying to access. Using umask 000 is generally considered a Bad Idea™. It’s the same as giving write access to Everyone on any file you create.
If you want the full background, I suggest reading up on POSIX and ACL-based file permissions. If I remember correctly, Synology’s DSM uses its own style of ACL which is managed by a local database.
Cool, I think (better for him) that he has read. But I understand also that he will not enabled “everyone”. (I try (two years ago the same), and I haven’t found a solution.)
He know (I hope) the risks, also let him try… Perhaps something has changed, perhaps he found something what we hav’nt found, perhaps fall down the the hell.
Give him the time to try, and if necessary I think you also are ready to help.
Michael
PS: I will not remember the number of … “experiences”, after then I restart from scratch. But I was be a little bit younger, and also it’s wasn’t every time my faults.
Using the standard UNIX permissions, there are a few mechanisms we can use to get over the issue of UIDs not matching without needing to grant global permission on everything:
We can create a GID on the client box with the same GID as on the server. Then for those people we want to access the NFS share, the client-box administrator can add them to that secondary group. So now, even though UIDs don’t match, selected users get access on the basis of one (or more) of their secondary GIDs matching the GID(s) on the NFS server.
Another much more broad-brush approach is for the server to specify all_squash, anonuid=xxxx, anongid=yyy in the /etc/exports file. This has the effect of forcing all users on the client box, including root, to access the data using a UID of xxx and a GID of yyy. In a domestic setting this usually works just fine and has the benefit of being simple to set up.
IMO, wherever possible, the use of ACLs should be avoided on a home network, since they’re simply overkill.
For a normal NFS setup on a linux/bsd/whatnot I will agree, but this is a Synology box we’re talking about and most people aren’t really comfortable firing up SSH and ye olde vi to start editing config files on a proprietary system.
For option 1, you need to take into account that all clients have to switch their primary GID and to umask 002 if they want others to edit the same files. Or you can force the GID with a setgid bit, but I don’t know whether that is possible via the Synology ACLs.
Option 2 is what I use on my home network, but it involves editing the /etc/exports on the Synology directly, with no guarantee that it won’t get overwritten at some point by the DSM software.
ACL’s are indeed more of a hassle than anything else, but again, on the Synology it’s built-in so as to be applicable to folders that are shared to both NFS and SMB clients. In any case, you shouldn’t come into contact with those ACLs directly (unless you really know what you’re doing).
Under the covers, Synology seems to behave like a normal v3 NFS server but the (5.2) interface has one notable omission which is the all_squash with anonuid and anongid I mentioned. But as long as people are willing to SSH and edit files, they should be able to get a reasonable set-up. And don’t forget that this is OSMC where the command line interface is frequently necessary, so we’re a hardy bunch over here…
That’s not my experience. A secondary group should normally be sufficient for read-only access. And on a home network, option 2 is a preferable method, anyway. (I see you use it yourself.)
Indeed, that’s what I’d use for r/w access. I’ll have to give it a try on Synology, though I only have access to a friend’s 5.2 box. I think it supports ACLs.
Thanks a lot for all this informations, this is a confirmation to everything I have recently read.
I didn’t tried yet, because I’m not confortable by creating users directly via ssh on my syno.
Is it safe?
Is the gid as important as the uid?
I’m interesting in removing permission to everyone if I can autorize only few ips. Is it possible in Syno?
Thanks!