CIFS or NFS or what? Problems with timestamps and rights

[kitaets]

Maybe this question was already discussed but I have read a lot of topics and haven't found an answer.
I need to give different access rights to different home users working on one Ubuntu PC.
As I see NFS is recommended for Linux but in v.3 it's impossible to give different rights. So I need to use CIFS. But I have another problem: when I connect from Windows PC CIFS works perfectly but when I use Ubuntu PC and copy files to QNAP with CIFS I loose files timestamps (checked in v.3.7.1).
So what can I do? I need to use Ubuntu and Windows and I need to preserve timestamps of copied files and need to give different rights.
Are Linux users unlucky with QNAP?
It's strange that Windows clients work better with Linux server than Linux clients

[schumaku]

As I see NFS is recommended for Linux but in v.3 it's impossible to give different rights.

That's in the nature of NFS - the access rights are managed on the client side - this is not a NAS shortcoming. The QNAP NAS are almost standard Linux systems, providding NFSv3 and NFSv4(.1) services.

So I need to use CIFS. But I have another problem: when I connect from Windows PC CIFS works perfectly but when I use Ubuntu PC and copy files to QNAP with CIFS I loose files timestamps (checked in v.3.7.1).

So what can I do? I need to use Ubuntu and Windows and I need to preserve timestamps of copied files and need to give different rights.
Are Linux users unlucky with QNAP? It's strange that Windows clients work better with Linux server than Linux clients

Not a QNAP issue at all. Diffeent operating systems behave different: Windows does copy the file and does set the archive bit (so backup programs recognize it as a new file), while Linux does aply a new creation date - there is no difference if using a local file system, NFS, CIFS, or whatever mounts.

Bottom line: Not a NAS issue - lack of user eduaction instead. You need to adopt your working logic (or whatever is referencing to the file creation date) to be compatible with your choosen workstation OS.

[kitaets]

That's in the nature of NFS - the access rights are managed on the client side - this is not a NAS shortcoming. The QNAP NAS are almost standard Linux systems, providding NFSv3 and NFSv4(.1) services.

Hmmm... I've tried "mount -v..." for NFS and Ubuntu said me that the server didn't know NFS v.4 so it connected with v.3:

Code: Select all

mount nfs 192.168.1.102:/Public /home/kitaets/NAS/NFS port=2049
mount.nfs: timeout set for Fri Aug  3 18:44:25 2012
mount.nfs: trying text-based options 'port=2049,vers=4,addr=192.168.1.102,clientaddr=192.168.1.137'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'port=2049,addr=192.168.1.102'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 45203
192.168.1.102:/Public on /media/Docs/Coding/NFS type nfs (rw,port=2049)

Diffeent operating systems behave different: Windows does copy the file and does set the archive bit (so backup programs recognize it as a new file), while Linux does aply a new creation date - there is no difference if using a local file system, NFS, CIFS, or whatever mounts.

As I see you said that if my system doesn't preserve timestamps in CIFS it also doesn't preserve timestamps in neither NFS nor SSHFS. But it does, it preserves timestamps in NFS and SSHFS. But not in CIFS.

Not a NAS issue - lack of user eduaction instead. You need to adopt your working logic (or whatever is referencing to the file creation date) to be compatible with your choosen workstation OS.

Ok, that's why I'm asking, so what can I do? The authentication can be based on user or on PC. I need first because I have two home PCs and three users. But authentication based on user works only for CIFS as I see. Am I not right?

[schumaku]

...unless I'm wrong ...when copying (cp) a file in Linux, it will get a new date, unless when using the -p(reserve_date). The exception is when you are moving (mv) a file.

When considering NFS all users and groups need to have the same gid and uid, umasks should be set accordingly for example. While a quick workgroup set-up can be done in a short time using SMABA, AFP, ftp, ... NFS requires much more insight and network manaement efforts.

When it comes to higher level protocols, the authentication and access control is done on the NAS, while for NFS, thee is nothing compareable - at leat nothing that comes to the same simplicity.

NFSv4 is not enabled on older NAS firmware - and will not give you any advantage anyway.

[kitaets]

...unless I'm wrong ...when copying (cp) a file in Linux, it will get a new date, unless when using the -p(reserve_date). The exception is when you are moving (mv) a file.

A bit different:

Code: Select all

man cp
...
--preserve[=ATTR_LIST]
              preserve the specified attributes (default: mode,ownership,timestamps),
              if  possible  additional attributes: context, links, xattr, all
...

So I have already tried "cp --preserve=timestamps..." with CIFS connection but got message "operation is not allowed". It means that server declined this option. I want to believe that I do something wrong on PC but I have been digging Ubuntu/Linux manuals and forums and found nothing

When considering NFS all users and groups need to have the same gid and uid, umasks should be set accordingly for example...

Yeah sadly NFS is not "out-of-the-box" way to give different rights to different users, that's why I'm trying to use CIFS.

NFSv4 is not enabled on older NAS firmware - and will not give you any advantage anyway.

I use fresh 3.7.1 on new HDD.