newsyslog errors

[CLSegraves]

My FreeNAS box emailed me these error messages this morning. I tried researching but I'm still not sure what they mean.

• newsyslog: change_attrs couldn't chmod(/var/log/nginx-access.log.0): Operation not permitted
• newsyslog: can't fchmod temp file '/var/log/nginx-access.log.zU2O91O': Operation not permitted
• newsyslog: change_attrs couldn't chmod(/var/log/maillog.1.bz2): Operation not permitted
• newsyslog: change_attrs couldn't chmod(/var/log/maillog.0): Operation not permitted
• newsyslog: can't fchmod temp file '/var/log/maillog.zXMa1f3': Operation not permitted
  

Thanks in advance,

Chris

 

[anodos]

It appears that you probably either (1) changed the aclmode of your .system dataset or (2) changed the ownership of your .system dataset. My working hypothesis is that you recursively changed ACL type or permissions on your pool. You can verify by posting the output of the following comands:

Code:

ls -l /var/log
zfs get aclmode [pool]/.system

The third option is of course that your USB died. :)

 

[CLSegraves]

Thanks. I don't think it's my USB (as the USB is only being used for the flash drive that FreeNAS is on).

Here is the output.

Code:

[root@NAS01 ~]# ls -l /var/log
lrwxr-xr-x 1 root wheel 34 Sep 10 12:56 /var/log -> /mnt/NetDrive01/.system/syslog/log

[root@NAS01 ~]# zfs get aclmode NetDrive01/.system
NAME                     PROPERTY      VALUE          SOURCE
NetDrive01/.system       aclmode       restricted     inherited from NetDrive01

I just created this new pool yesterday (changing my NAS around, combining data that was on multiple pools, setting up hot spares, etc.). I had to change the permissions (forgot to set the group) after I had already moved data over so I did it recursively.

Should I have not done that? I was under the impression that once data has been placed on the pool, the permissions have to be applied recursively in order to apply the updated permissions to the data. Is that not correct?

I'm using Windows ACL permissions. Each user (my family members) have their own user name. We all belong to the same group (surname) which gives us all unlimited permission to the data.




Side question:
When I go into "View Users", the documentation says there should be a "Change Password" and "Change E-mail" options, however I only see the "Modify User" and "Remove User" options. Did those get moved into the "Modify User" option (I see email and password in there but just want to confirm these are one and the same).

 

[CLSegraves]

So I stumbled onto something odd:

When I check the permissions in Windows (NetDrive -> Properties -> Security), if I have the family (surname group) as the Owner group I get an error (in the Windows security "Group or user name") that says "Account Unknown(s-1-5-21.....etc)". The error (s-1-5-21....etc.) is the same error that just pops up in the console message.

When I set the Owner group to anything else (wheel, operator, daemon, etc.), Windows shows the right group name (wheel, operator, daemon, etc.).

Why wouldn't my custom group be working?

 

[anodos]

Thanks. I don't think it's my USB (as the USB is only being used for the flash drive that FreeNAS is on).

Here is the output.

Code:

[root@NAS01 ~]# ls -l /var/log
lrwxr-xr-x 1 root wheel 34 Sep 10 12:56 /var/log -> /mnt/NetDrive01/.system/syslog/log

[root@NAS01 ~]# zfs get aclmode NetDrive01/.system
NAME                     PROPERTY      VALUE          SOURCE
NetDrive01/.system       aclmode       restricted     inherited from NetDrive01

I just created this new pool yesterday (changing my NAS around, combining data that was on multiple pools, setting up hot spares, etc.). I had to change the permissions (forgot to set the group) after I had already moved data over so I did it recursively.

Should I have not done that? I was under the impression that once data has been placed on the pool, the permissions have to be applied recursively in order to apply the updated permissions to the data. Is that not correct?

I made a typo previously. Run [ls -l /var/log/]
The short answer is that the aclmode for windows acltype prevents chmod and chown operations. There is no reason to switch an entire pool to have windows acl type. This should be handled at a dataset level. Create datasets, choose permission type, share them.

 

[CLSegraves]

So is there no benefit to using windows acl over unix acl?

Do I need to wipe the pool and start over or is this a correctable error?

 

[anodos]

So is there no benefit to using windows acl over unix acl?

Do I need to wipe the pool and start over or is this a correctable error?

There is plenty of benefit of Windows ACLs. You just should set them on your datasets and not your zpool. For example if you want to create a share named "FOO" do the following: create a dataset named "FOO", configure Windows ACLs for "FOO", create a CIFS share for "FOO".

You don't need to restart. Just recursively set the permissions type on your zpool to "Unix" and then run "zfs get aclmode [pool]/.system" It should be "passthrough". If for some reason the previous step doesn't change the aclmode of your system dataset then run "zfs set aclmode=passthrough [pool]/.system". Once that problem is fixed, create some datasets and move your data to the datasets.

The problem you appear to be having with SID mapping may be related to the permissions in your .system dataset being jacked. Fix the permissions as I wrote above and see if the problem persists.

 

[CLSegraves]

OHHHHHH.... okay. I had always just been sharing the mnt point. Okay, learned something new. Thanks!

 

[anodos]

OHHHHHH.... okay. I had always just been sharing the mnt point. Okay, learned something new. Thanks!

Doing it the way I explained gives you more flexibility. It allows setting features like compression, atime, Windows ACL type, etc for some shares but not others. It also allows more heavily customized snapshot and replication policies.

 

[CLSegraves]

Okay, so I recursivley set the acl mode to Unix.

Then checked the acl mode with the 'get acl' command. Here is what I got:

Code:

[root@NAS01 ~]# zfs get aclmode NetDrive01/.system
NAME                  PROPERTY      VALUE            SOURCE
NetDrive01/.system    aclmode       restricted       inherited from NetDrive01

So I changed it to passthrough:

Code:

[root@NAS01 ~]# zfs set aclmode=passthrough NetDrive01/.system

And then rechecked:

Code:

[root@NAS01 ~]# zfs get aclmode NetDrive01/.system
NAME                  PROPERTY      VALUE            SOURCE
NetDrive01/.system    aclmode       passthrough      local 

So my acl mode on the pool should be set.

Now I should be able to go create datasets with Windows acl and move my data over. Everything looking correct?

 

[CLSegraves]

Anything wrong with creating datasets and setting the specific acls for each dataset, yet still sharing the root pool? Because this is a home NAS that the entire family has access to, I'd rather not have to map multiple shares.

 

[anodos]

Anything wrong with creating datasets and setting the specific acls for each dataset, yet still sharing the root pool? Because this is a home NAS that the entire family has access to, I'd rather not have to map multiple shares.

I'd still rather create things like [zpool]/[root_dataset_to_be_shared]/[other_datasets] than sharing out the entire zpool. Once again this is to avoid accidentally screwing up your .system dataset. Way back in the days when I first started working with windows file sharing a senior admin told me "Never share drives - only share folders." The same reasoning applies to sharing out your entire zpool. If possible, share datasets or folders within datasets. Don't share your entire pool.
Or you can simply create a single dataset to share and manage access controls to subdirectories in the normal Windows way through the "security" tab in windows explorer (in windows this will require unchecking "inherit permissions from parent" [or whatever it is called]).

 

[CLSegraves]

I'd still rather create things like [zpool]/[root_dataset_to_be_shared]/[other_datasets] than sharing out the entire zpool. Once again this is to avoid accidentally screwing up your .system dataset. Way back in the days when I first started working with windows file sharing a senior admin told me "Never share drives - only share folders." The same reasoning applies to sharing out your entire zpool. If possible, share datasets or folders within datasets. Don't share your entire pool.
Or you can simply create a single dataset to share and manage access controls to subdirectories in the normal Windows way through the "security" tab in windows explorer (in windows this will require unchecking "inherit permissions from parent" [or whatever it is called]).

Okay, that makes very good sense now that you point it out. Some while back I completely killed my SAMBA interface due to the permissions getting all messed up on my ZFS volume. Every time I would import the volume SAMBA would crash. The only solution was to wipe all of the volumes and start over. Fortunately I had a backup so no harm done. I assume that by doing datasets I avoid this possibility?

I could just do a first level dataset (volume/dataset) and share that correct?

On the datasets, do I want to just inherit the compression level or should I set each individual one to lz4 (the default for the volume)?

 

[anodos]

Okay, that makes very good sense now that you point it out. Some while back I completely killed my SAMBA interface due to the permissions getting all messed up on my ZFS volume. Every time I would import the volume SAMBA would crash. The only solution was to wipe all of the volumes and start over. Fortunately I had a backup so no harm done. I assume that by doing datasets I avoid this possibility?

On the datasets, do I want to just inherit the compression level or should I set each individual one to lz4 (the default for the volume)?

Yes, this structure change should avoid that problem. Leave compression level on "inherit" unless you have specific reason not to. Sometimes I disable atime on datasets. In general, leaving things on default is fine (there's a reason why they're the defaults). Samba defaults should also be pretty good (avoid the weird samba voodoo with socket options and other such settings).

 

[CLSegraves]

I really appreciate your help/guidance. They need a thumbs up smiley here. :D

 

[pschatz100]

Okay, that makes very good sense now that you point it out. Some while back I completely killed my SAMBA interface due to the permissions getting all messed up on my ZFS volume. Every time I would import the volume SAMBA would crash. The only solution was to wipe all of the volumes and start over. Fortunately I had a backup so no harm done. I assume that by doing datasets I avoid this possibility?

I could just do a first level dataset (volume/dataset) and share that correct?

On the datasets, do I want to just inherit the compression level or should I set each individual one to lz4 (the default for the volume)?

Using datasets gives you more control over setting permissions and other attributes for specific sets of directories or files. Also, if you mess up one dataset, your problems are confined to that one dataset.

I think you are on the right path: create a dataset, then create directories within the dataset as you wish. You could then easily set any attributes for the dataset that you want to apply recursively to all the directories. If you wanted more control, you could create datasets within the main dataset and set features for each one as you see fit, but that starts to get complicated.

I wouldn't obsess over compression. The default lz4 compression is very efficient - read up on this. I stick with FreeNAS defaults unless I have a specific reason to change them, and have yet to see any problem with this.

 

[CLSegraves]

Thanks. Hopefully I'll have less issues not going forward.