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: Code:
[public] |
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 Code:
[public] Code:
/home/samba/public/stock# ls -la 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: Code:
$ ls -l I changed the permissions to the following, after each change I had the user either restart or refresh Windows Explorer: Code:
-rwxrwx--- 1 ohprso ohprs 5276494 2024-01-24 11:17 Healthcare-\ Smith,\ Terry\ Lee.pdf* 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? |
Quote:
Code:
X:\Pension Files\McGill, Terry L\Insurance>attrib 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: Code:
[Users] Code:
CREATOR OWNER:Full control:Subfolders and files only 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:
Code:
vfs objects = acl_xattr The fstab for the volume containing this share does have user_xattr, but I've tried with and without that option too. |
Quote:
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.
|
All times are GMT -5. The time now is 11:23 AM. |