CIFS Files showing 24-01-1984 as date on OSX

[jonandermb]

Hi. I'm having a weird problem.
I have this CIFS Share I access from windows and OSX computers.
I have no problem accessing them from windows whatsoever, but when I access them from Mac, they are grayed out (kind of blocked) and their date is 24th january 1984. I know it's an important date for Macintosh and bla bla... the story behind this date is not strange for me, but... why is this happening, and how to fix it?

Thanks!


EDIT: Doing xattr -c <filename> fixes it for a while. After some time, it get's locked again. This is bugging more than what it should

 

[cyberjock]

Honestly, sounds kind of like you have a virus or something that is playing games with you. I've never heard of this from a FreeNAS server before, so I tend to think this is something being set by one of your workstations.

 

[anodos]

Hi. I'm having a weird problem.
I have this CIFS Share I access from windows and OSX computers.
I have no problem accessing them from windows whatsoever, but when I access them from Mac, they are grayed out (kind of blocked) and their date is 24th january 1984. I know it's an important date for Macintosh and bla bla... the story behind this date is not strange for me, but... why is this happening, and how to fix it?

Thanks!


EDIT: Doing xattr -c <filename> fixes it for a while. After some time, it get's locked again. This is bugging more than what it should

What are the exact steps you are performing when you state "doing xattr -c <filename>"?

Post the following:

• smb4.conf file (located at /usr/local/etc/smb4.conf)
• server hardware specs
• version of FreeNAS
• contents of /var/log/samba4/log.smbd with increased verbosity when accessing the share from a Mac
• contents of /var/log/messages when accessing the share from a Mac (and the problem manifests itself).

What types of files are you working with? (Are these adobe files?)

 

[mjws00]

On mountain lion (and later?) a partial download is created with that date as an easter egg. They also exhibit that greyed out behaviour while incomplete (locked?). Not sure what is triggering it on a whole file. But it is possibly as simple as a file lock not being reset properly? Are you sharing the same files via AFP and CIFS?

Anodos is way harder core on the samba than I am. So you're in good hands.

 

[anodos]

Anodos is way harder core on the samba than I am. So you're in good hands.

I'm not really hardcore. I just use it at work. Interpreting samba documentation, which is delphic at its best, is more of an art than a science. :)

 

[jonandermb]

Sorry for the delay, I was out of the office.

Here's smb4.conf file: Note, I try to control the creation of cache files via veto parameters: I removed such functionality because it was giving me a lot of problems when copying files and folders.

The share named "Digital" is the one I found the problems on.

Code:

[global]
    server max protocol = SMB3
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 11070
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = Yes
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    server string = NASSamper FreeNAS Server
    ea support = yes
    store dos attributes = yes
    time server = yes
    acl allow execute always = true
    idmap config *:backend = tdb
    idmap config *:range = 90000000-100000000
    server role = member server
    netbios name = NASSAMPER
    workgroup = DOMSAMPER
    realm = DOMSAMPER.LAN
    security = ADS
    client use spnego = yes
    cache directory = /var/tmp/.cache/.samba
    local master = no
    domain master = no
    preferred master = no
    acl check permissions = true
    acl map full control = true
    dos filemode = yes
    winbind cache time = 7200
    winbind offline logon = yes
    winbind enum users = yes
    winbind enum groups = yes
    winbind nested groups = yes
    winbind use default domain = no
    winbind refresh tickets = yes
    idmap config domsamper: backend = rid
    idmap config domsamper: range = 20000-20000000
    allow trusted domains = no
    template shell = /bin/sh
    template homedir = /home/%D/%U
    pid directory = /var/run/samba
    smb passwd file = /var/etc/private/smbpasswd
    private dir = /var/etc/private
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 10


[Backup]
    path = /mnt/Backup/Backup
    printable = no
    veto files = /.snap/.windows/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-2w
    vfs objects = shadow_copy2 zfsacl streams_xattr aio_pthread
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
    zfsacl:acesort = dontcare
    veto files = /Temporary Items/.DS_Store/._.DS_Store/._.TemporaryItems/Thumbs.db/.Apdisk/.TemporaryItems/
    delete veto files = yes


[Digital]
    path = /mnt/STORAGE/Digital
    printable = no
    veto files = /.snap/.windows/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-2w
    vfs objects = shadow_copy2 zfsacl streams_xattr aio_pthread
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
    zfsacl:acesort = dontcare


[STORAGE]
    path = /mnt/STORAGE
    printable = no
    veto files = /.snap/.windows/.zfs/
    writeable = no
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-2w
    vfs objects = shadow_copy2 zfsacl streams_xattr aio_pthread
    hide dot files = no
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
    zfsacl:acesort = dontcare


[Software]
    path = /mnt/STORAGE/Software
    printable = no
    veto files = /.snap/.windows/.zfs/
    writeable = yes
    browseable = yes
    recycle:repository = .recycle/%U
    recycle:keeptree = yes
    recycle:versions = yes
    recycle:touch = yes
    recycle:directory_mode = 0777
    recycle:subdir_mode = 0700
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-2w
    vfs objects = shadow_copy2 zfsacl streams_xattr aio_pthread
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = yes
    zfsacl:acesort = dontcare
    veto files = /Temporary Items/.DS_Store/._.DS_Store/._.TemporaryItems/Thumbs.db/.Apdisk/.TemporaryItems/
    delete veto files = yes

The server is a Dell Power Edge 2950: 4x 1 TB HD on RAIDz (2.8Tb of available space)
14 Gb RAM

Freenas Version is the latest one. I usually upgrade a few days after new versions are released.

Since I disabled the veto files and the "export recycle bin" option, the problems seem to be gone: At least, some files that yesterday were "locked", today seem accessible and with a correct date.

Anyway, I get the message "Warning: the "acl check permissions" option is deprecated" a lot.

I didn't post the log messages because they don't show anything related to those files, since they don't seem locked anymore.
Weird: I'll keep an eye on the subject during the day and report back with logs if I see it happen again.

Thanks


EDIT: Also: I have some issues when copying files from these samba shares to other network shared folders shared via normal windows share (right click, share, on some computers)
If I try this from mac, it would ask me for elevated permissions (password) and then, complain that I don't have permissions to read the files.
Weird, because if i copy those files to my local Mac HD, I have no problem at all, but then, if I try to copy again to that other network shares, I still get the error message. Seems like a permissions issue to me, or some file creation mask or so.
BTW: I hate Mac myself, but I'm forced to use it. I suffer NONE of these problems on my windows machines....

The owner of the share is nobody:nogroup and I set permissions for everyone to be able to read, write and modify.
The Mac clients connect using an Active Directory account, but they use local users.

 

[anodos]

I'm not a Mac person and so my knowledge is about ankle-deep. OSX typically stores metadata in resource forks. Getting these to operate nicely with samba is an ongoing challenge. Your shares have the parameter vfs objects = streams_xattr, which attempts to replicate NTFS's ability to store resource forks as "alternate data streams". This implementation has some limitations. Specifically, I believe it fails once the metadata exceeds a certain size and falls back to storing the resource fork as a file in the share. Your veto parameters were basically killing the metadata that OSX was expecting to have for your files. (Hence running "xattr -c" temporarily fixed the problem). The good news is that the samba folks are working on a better way of handling resource forks "vfs fruit". I'm not sure when it is expected to be released.

The message regarding "acl check permsissions" is benign. I can't comment on your other sharing issue, except to say that it sounds like a trust issue. Have you tried joining the Macs to your domain and having people use AD credentials?

By the way, hardware RAID on FreeNAS is a terrible idea.

 

[jonandermb]

By the way, hardware RAID on FreeNAS is a terrible idea.

I know, I know, I know, I know..... I know.
I had this chat some months ago with cyberjock :)
I have another server running freenas. Custom made with server grade hardware. A proper implementation.
This other server is a recycled one. Actually, once upon a time, we had two of these: I took the hard disks from the older one and put them on the new one. Bought some second hand RAM and upgraded it from 4 Gb (ouch) to 14 Gb.
It's old: Yes.
It consumes too much energy: Sure
This time I tried an approach setting every disk as raid0 and letting freenas manage every disk as a single disk: Yes, shitty, but does the job for two simultaneous users and we have to save money... (I should have gone with the approach of making two raid5 devices, but now that I realized after restoring, I don't want to go through all the backup and restore process again)
At least I'm using server grade hardware and ECC memory, which IMO is a relief.
The server is not optimally configured?: Yes, but not because of lack of knowledge, but because it's expendable and I make periodic backups.

About the samba problems: I noticed improvement since the moment i removed the veto files restrictions. The other problems with read permissions remains a mystery.

PS: Mac sucks


Thanks for your help-

 

[anodos]

About the samba problems: I noticed improvement since the moment i removed the veto files restrictions.

Which is to be expected.

The other problems with read permissions remains a mystery.

I noticed that your FreeNAS box is configured as an AD member server. Have you tried joining your Macs to your domain and using domain credentials?

PS: Mac sucks

All computers suck.

 

[jonandermb]

The macs are in the domain: The users, however, are local users: Not AD users (Perhaps it's time I start using AD users with those)
I noticed this problem since the moment I included the other computers inside the AD.
When connecting to them, I specify username and password of a AD user: The connection succeeds, but then, I guess i run into these other problems.
I'll try using AD users with the macs and see if the problem persists.

All computers suck: But I prefer when they are cheaper, and more open. Mac sucks the most.

 

[anodos]

The macs are in the domain: The users, however, are local users: Not AD users (Perhaps it's time I start using AD users with those)
I noticed this problem since the moment I included the other computers inside the AD.
When connecting to them, I specify username and password of a AD user: The connection succeeds, but then, I guess i run into these other problems.
I'll try using AD users with the macs and see if the problem persists.

All computers suck: But I prefer when they are cheaper, and more open. Mac sucks the most.

I know you have probably already tried this. When you pass credentials to a computer on a domain, you sometimes have to prefix the domain name to the user account. For instance: you are use bob on the domain foo.com, you should authenticate with "foo\bob", but sometimes you need to use "bob". One time I had to use "\\foo\bob", and I think I once had a CLI utility that required "foo/bob". That's a long way of saying that your mac may be passing credentials as "LocalComputer\bob" to your other machines rather than "foo\bob". Using domain accounts is easier.