SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
While configuring Samba on Box 2 to mount some NTFS partitions located on Box 1, I ran across a seemingly common error message from Konqueror. While using Konqueror to copy a file from my normal user's home directory to a shared NTFS-4 directory, Konqueror popped up a message that it could not change permissions.
I configured this particular shared NTFS Windows partition for full read/write permissions.
Suspecting that this message might be solely related to mounting permissions and not specific to Konqueror, I copied another file using the command line cp command. No error messages, so I then tried cp -p and sure enough I receive a similar error message.
Some surfing revealed that just about everybody reporting this problem does so only with FAT32 partitions. One solution offered is to include the quiet option in the mount command. I do have a shared FAT32 partition on my Windows NT4 box, and I had hoped that I could stop the error messages at least when mounting that partition. I tried the quiet option, but received the same error messages.
I also tried to no avail mounting with the noatime option.
All of this makes sense, of course, at least for "dumb" FAT32 file partitions. However, NTFS is a journaling file system and does track additional time stamps not maintained in FAT32. I would suspect that when copying files to an NTFS partition that the error messages would disappear, but that is not the case.
My mount command looks like this:
mount -t smbfs //box1/share_name /mnt/nt_share_name -o rw,quiet,credentials=/etc/samba/private/credentials,fmask=774,dmask=774,gid=users
The only way I can eliminate the messages is to mount the shared NTFS and FAT32 partitions as the user who actually does the file manipulations. Setting the gid option when mounting does not eliminate the messages. I must mount using the uid option as well if I hope to stop the nuisance.
From a personal perspective, mounting with uid is not a critical issue for me because I am the sole user and I have only two boxes in my simple network. Still, I prefer to learn and practice administrative skills as though I am maintaining numerous user accounts and boxes.
Specifically, Samba seems to be the culprit here by ignoring the quiet option. I realize that the quiet option applies only to FAT32 (vfat) partitions, but there seems to be no remedy for NTFS partitions either.
Please realize that I understand that the messages are normal and expected. I'm merely seeking a way to quiet or ignore the messages. I am having a challenging time believing that with all the people in this world using Samba that everybody tolerates and ignores this problem. Thus, I am more inclined to believe that a solution exists.
Otherwise, moving, copying, editing files, etc. all work just fine. The messages are merely a nuisance, but has anybody found any remedies?
Distribution: Slackware, CentOS. Red Hat Enterprise Linux
Windows network file shares do not work like NFS file shares. The fmask, dmask, uid and gid options are all designed to provide the necessary Linux file permissions to the this foriegn file system. They do not affect the NTFS or FAT32 partition on the remote server. The username that you used in the credentials file is the user that Windows uses to determine permissions and ownership for the NTFS partition. For example, if you used a user account that had read-only permission to the NTFS file system, you would not be able to create, modify or delete files even though you specified the rw option in the mount command because the Windows user can't either.
Nor do changing of permissions work. The Linux chmod function doesn't traslate to the Windows world and it always fails on an SMB mounted file system. The quiet option only surpresses messages generated when mounting the Windows file system but not when you operate on it, which is why you are always seeing these annoying messages.
The Linux chmod function doesn't translate to the Windows world and it always fails on an SMB mounted file system. The quiet option only surpresses messages generated when mounting the Windows file system but not when you operate on it, which is why you are always seeing these annoying messages.
Yes, that the chmod command does not translate is understandable. However, your answer implies that people who use Samba nonetheless tolerate these nuisance error messages. Strange. After all these years that Samba has been used, I'm surprised and scratching my head that the Samba maintainers do not provide a quiet option to suppress these messages, or simply route chmod operations on Windows shares to the bit bucket. Very strange. Then again, if I have learned anything about the 'nix way of thinking the past few years, I've learned that usability is not always a priority, which is one reason why 'nix remains relatively unpopular among the masses. Just my opinion, of course.
Distribution: Slackware, CentOS. Red Hat Enterprise Linux
It's usually good form to report back to the calling program if something doesn't work. But I wondering if the -p option is being automatically appended to your cp command by an environment variable. I generally don't see any error messages when copying to a SMB mounted share.