Red Hat Bugzilla – Bug 427951
SMB/CIFS does not copy files with leading periods in the name
Last modified: 2008-01-08 11:41:27 EST
Description of problem:
When copying files from a local folder to a SMB/CIFS share on a RHEL server
(using Nautilus, Konqueror or via the CLI), files that have a leading period (eg
.emacs) in the file name cannot be copied to the SMB/CIFS share. This occurs
whether one accesses the share via a normal smb:// URL or if the share is
mounted via an entry in /etc/fstab.
It is not clear to me if this is a problem on F8 as the client or on RHEL as the
server or both.
Filenames (and folders) with leading periods are legal on Windows. However, it
is noted that some Windows applications, such as Explorer, will preclude
allowing a user to create or rename a file containing a leading period.
A thread on the Fedora list on this is here:
The follow up that I will be posting shortly has some references to the MSDN and
Wikipedia with some references on this.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
With a console window open and with the working directory on the SMB/CIFS share:
$ cp /home/marcs/.emacs .emacs
cp: cannot create regular file `.emacs': No such file or directory
A .emacs file (using the above example) should be copied from the local folder
to the target share folder.
Just a quick follow up with a direct link to the references I mention above in
the Fedora list thread post:
What samba package do you use on RHEL ?
What client kernel driver are you using? cifs.ko ?
Do you see any error in the logs server side? (raise logs to 5 at least, 10
preferable for the test).
Thanks for your follow up.
Thanks to Les Mikesell on the Fedora list, who referenced a 'veto' setting in
smb.conf last night, I confirmed with our SysAdmin this morning that indeed:
veto files = /.*/
appears in the server's smb.conf.
Our SysAdmin commented out that line and reloaded Samba on the server, after
which I could copy these files without issue. Unfortunately, our SOP's require
this configuration, which our SysAdmin had forgotten about.
So, bottom line, we can close out this bug, which may be of help to others at
some future date.
No problem, marking as not a bug.