[SOLVED] PDF files on Samba share "disappear" after updating

I've recently updated a Linux/Samba file server from Slackware 14.2 to 15.0, and Samba 4.6.16 to 4.18.9, and our office is experiencing the weirdest thing ...

We use PhantomPDF to scan document to .pdf and to append pages to existing PDFs. This software is the same as before the upgrade and anyway runs on the Windows computers, not Linux.

When scanning to append pages to an existing PDF file on the Samba share, the file, after scanning and saving "disappears"! It can not longer be seen in Windows Explorer. Yet if someone tries to copy a file from elsewhere to this disappeared destination they are aked if they want to replace the file.

This only happens on appends to existing PDF files. New PDFs can be scanned, Word and Excel files can be modified -- nothing disappears in this case.

If logged onto Linux where the Share is hosted, the file is there.
The relevant Samba smb.conf section is below, unchanged from before the upgrade:

[public]
comment = OHPRS main file and document repository
path = /mnt/RAID/public
hide files = /Outlook/outlook/~*/

readonly = no
locking = yes
public = yes
printable = no
create mask = 0660
force user = user
force group = group
force create mode = 0660
directory mask = 2771

I am really stumped. Does anyone have any idea how this could be happening?

Just a thought - check the Linux file permissions on you Linux Samba box. Are the permissions of newly created files any different from these that were already there before your upgrade ?
Note that Samba runs on Linux and Linux permissions are different from Windows permissions. Samba tries to map them but you can define how this mapping works. You could have overwritten some mapping settings during your upgrade.
My gut feel is that if you change the permissions on the "old" pdf's to the same as the "new" pdf's have your problem will be resolved.

My share config looks like this

[public]
        comment = Public folder 
        path = /home/samba/public
        dos filetime resolution = yes
        write list = @smbusers
        force group = smbusers
# Forces the specified permissions (bitwise or) for directories created by Samba.
        force create mode = 0770
# Forces the specified permissions (bitwise or) for directories created by Samba.
        force directory mode = 0770
        readonly = no
        comment = Shared drive
        valid users = @smbusers
        create mode = 0770
        directory mode = 0770
# antivirus protection - block potential viruses		
        veto files = /autorun.inf/desktop.dll/
        strict allocate = yes

and the Linux permissions on files are

/home/samba/public/stock# ls -la
total 32M
drwxrwx---+ 7 user     smbusers 4.0K Jan 15 21:58 ./
drwxrwx---+ 8 root     smbusers 4.0K Jan 23 13:46 ../

-rwxrwx---+ 1 user     smbusers 1.8M Apr 27  2022 ClaRUN.dll
-rwxrwx---+ 1 user     smbusers 129K Apr 27  2022 ClaTPS.dll
-rwxrwx---+ 1 user     smbusers 129K Apr 27  2022 wasp.exe
-rwxrwx---+ 1 user     smbusers 1.8K Jan 24 05:23 Config.tps
-rwxrwx---+ 1 user     smbusers  16K Jan 22 12:04 LastEmail.Log

lack of execute by group Linux permission would result in Windows user not being able to run the program

Do you have a backup of your /etc folder before the upgrade? You could compare your configs before and after the upgrade.

The rule 'don't use GUI tools when troubleshooting (or ever)' applies to windows too. What are the permissions on these files on windows when listed with 'dir /a' or 'attrib'? Are they hidden by any chance? Execute bits are masked out, so 'map hidden' cannot be a factor, but 'store dos attributes' can.

More info. First, to point out this only happens when scan/appending pages to an existing PDF file. When scanning to a new file there is no problem. After the scan/append and the user saves the file, it disappears from Windows Explorer, but is visible on Linux. The user's work-around is, in stead of saving to the original location, she saves to her desktop, then copies to the original folder -- she does get the "file exists" warning, so even if she can't see the file in Explorer, Windows knows it's there. After copy from the desktop, she can then see the file.

The permissions on the file after the scan/append:

$ ls -l
total 5168
-rw-rw---- 1 ohprso ohprs 5276494 2024-01-24 11:17 Healthcare-\ Smith,\ Terry\ Lee.pdf

Of course there are other, older files in this directory with the same permission scanned several years ago which are perfectly visible.

I changed the permissions to the following, after each change I had the user either restart or refresh Windows Explorer:

-rwxrwx--- 1 ohprso ohprs 5276494 2024-01-24 11:17 Healthcare-\ Smith,\ Terry\ Lee.pdf*

-rw-rw---x 1 ohprso ohprs 5276494 2024-01-24 11:17 Healthcare-\ Smith,\ Terry\ Lee.pdf*

-rwxrwx--x 1 ohprso ohprs 5276494 2024-01-24 11:17 Healthcare-\ Smith,\ Terry\ Lee.pdf*

The user could not see the file after any of these permission changes. I then has the user copy a saved image of the new file from her desktop to this folder and it then appeared on her Windows Explorer. Permissions same as above. I then deleted the file on Linux and had her copy from the desktop again. Again, visible to her with the same 0771 permissions.

So, even when I set the permissions to 0771 (last example), she could not see the file. Only her copying the file from the desktop made it visible. This must be something other than a permissions issue.

It should also be noted that when a user does copy a file from her desktop, or scans a brand-new file, it does so with 0771 permission, not the 0660 as specified in the smb.conf.

If the user creates a brand-new scanned file (permissions 0771) it is visible. But if she then appends page(s) to this file it disappears from Explorer, permissions remain 0771.

Other ideas?

Originally Posted by lvm_ The rule 'don't use GUI tools when troubleshooting (or ever)' applies to windows too. What are the permissions on these files on windows when listed with 'dir /a' or 'attrib'? Are they hidden by any chance? Execute bits are masked out, so 'map hidden' cannot be a factor, but 'store dos attributes' can.

attrib:

X:\Pension Files\McGill, Terry L\Insurance>attrib
A                    X:\Pension Files\Smith, Terry L\Insurance\Healthcare- Smith, Terry Lee.pdf
A   H                X:\Pension Files\Smith, Terry L\Insurance\test.pdf

The "Healthcare- Smith, Terry Lee.pdf" file is the one the user copied from her desktop to this folder which subsequently became visible. The test.pdf is the new scan she created, which was visible when she did that, and then appended a scanned page to it whereupon it "disappeared". As you can see, the H attribute is now set.

Note also that if the user creates a new scanned PDF on her desktop (it is visbible), then scan/appends a page to it, it is still visible. So this phenomenon only seems to occur when scanning to the Samba share.

Now, the interesting wrinkle with that last statement is that the user's Desktop is ALSO a Samba share (Redirected Folders) on a different host with the same Slackware 15.0 version and the same Samba 4.18.9 version. There is a difference in the smb.conf section. The share for the desktops is:

[Users]
    path = /redirectedFolders/Users
    comment = user folders for redirection
    read only = No

That directory further has the following Windows security permissions:

CREATOR OWNER:Full control:Subfolders and files only
Domain Admins:Full control:This folder, subfolders and files
Authenticated Users:Traverse Folder/Execute file,List folder/read data,Read Attributes, Create folders/append data:This folder only
SYSTEM:Full Control:This folder, subfolders and files

Do I blame the PhantomPDF program or the new version of Samba? Note that prior to upgrading Samba this never happened and the version of PhantomPDF has not changed. Nor does this H attribute get set when creating a new scanned file, nor when appending to existing PDF files on a different Samba share. Also, as I mentioned in my previous message, the new files are not being created with the 'force create mode' permissions (0660) specified in smb.conf.

More thoughts on this?

Just throwing out a big WAG. See what happens if you set "store dos attributes = no" for that share. This was set from default = no to yes in versions 4.9.0+. Combined with the other masks set for that share versus the share that works and/or if you are using the user_xattr mount option.

I've added "store dos attributes = no" to the file server's smb.conf. I'll have to wait until Monday when the office opens to see if it works. That smb.conf also has:

vfs objects = acl_xattr
map acl inherit = yes

Per the recommendation of the Samba Wiki: https://wiki.samba.org/index.php/Set..._domain_member, and "experts" on the samba@lists.samba.org list, but I've tried with and without those settings.

The fstab for the volume containing this share does have user_xattr, but I've tried with and without that option too.

Originally Posted by michaelk Just throwing out a big WAG. See what happens if you set "store dos attributes = no" for that share. This was set from default = no to yes in versions 4.9.0+. Combined with the other masks set for that share versus the share that works and/or if you are using the user_xattr mount option.

Yes! That "store dos attributes = no" worked. Scan/appended files are no longer hidden. I upgraded from version 4.6.16 to 4.18.9, so this "default" apparently changed during that, as you note. This is not the first instance during this updgrade where Samba and associated tools' default behavior has changed. I sent a mini-rant to the sambalist on another such change that caused problem with production scripts.

Thanks - I'm curious how you happened to know about this default change? I've struggled for over a week on this not knowing about this and would have continued to do so if not for your advice.

Just a lucky find reading the samba smb.conf documentation.