Only version 3.X of smbfs recognises the Unix extensions; version 2.X ignores them and uses the uid= and gid= parameters. I ended up with less functionality after the upgrade from 2.X to 3.X. What happens is that the uid (user id) and gid (group id) of the server files are transmitted (as meta data) by the server, and used verbatim by the client. My userid ("emmerik") is the same on my Linux machine and on the server, but the uid's are different (500 on my Linux machine, 10043 on the server). (Use the id command to find your uid, gid, etc.) Groups are also different between the two machines; in fact, my Linux machine only comes with one group (also "emmerik"). Ordinarily, that would mean that I would not be able to write to files on the server that don't have write permissions for "other", since I don't appear to own them (user 10043 does), and I'm not in the group 10000 ("users" on the server). So smbfs does some magic to allow me to write to files on the server. However, I could not create files in directories on the server; I would be told "Permission denied". Despite this, I could write to existing files. These files could be created by the root user using smbfs, or of course by my ordinary self on the server if I ssh to the server.
I wanted to run a Linux application (LyX) and yet make use of the University's nightly backups of my thesis files. I was actually able to work like this for several months (creating new files as needed from an ssh window), but it was very frustrating. After much searching, it seems to me that this is a bug in smbfs, which may be fixed in Fedora Core 4. I'm not up to recompiling the kernel, which may also solve the problem. It seems that Samba treats the creating of files as something of a special case, and something about my system causes that special logic not to work. I have found two workarounds for this: creating a new user with the same id as on the server, and modifying the userid of my main user (thanks, Coniptor!). The latter is most likely the best solution, although of course it will only work for one server.
Creating a new user
Note: I strongly recommend the second solution; see below.
# /usr/sbin/groupadd -g 10000 users2 # Create a group with a specific gid # /usr/sbin/useradd -g users2 -G emmerik emmerik2 # Create a user with a specific uid # passwd emmerik2 # Set a password for the new userYou may need to use -s /bin/bash; modify an existing user with /sbin/usermod .... I added the extra group "emmerik" so that I can easily get access to my own files, by just giving them group read or write access.
I then made two soft links from my home directory to the new users's home directory:
# cd /home/emmerik2 # ln -s /home/emmerik/.lyx . # ln -s /home/emmerik/texmf .I also tried using -d /home/emmerik to make the new user have the same home directory as usual login, but this didn't work. I ended up with all sorts of protection issues, and I could not use any X programs after that, since X seems to check that certain files have certain uids. Weird.
So finally, after I have all this set up, in my LyX screen, I simply su emmerik2 to "become" the new user, and now I own all the files on the server that I should, and I don't have trouble creating files any more. It's not perfect, but it works well enough.
For reference, here is the /etc/fstab entry I use (all on one line):
//raid/emmerik /home/mango smbfs users,noauto,nodev,fmask=664,dmask=775 0 0At one stage I used the .smbcredentials file by adding credentials=/home/emmerik/.smbcredentials, to store my userid and password (suitably protected of course). It's more secure to leave this out and just enter the password whenever you mount (with mount //raid/emmerik).
Modifying the id of your login
This solution is courtesy of Coniptor... thanks!
# vim /etc/passwd Change uid and gid of user emmerik from 500 to 10043 # vim /etc/group Change gid of group emmerik from 500 to 10043 # cd ~emmerik # chown emmerik:emmerik . # chown -R emmerik:emmerik * # chown -R emmerik:emmerik \.* # rm .Xauthority # A new one will be created next loginCheck that the hidden files (ones that start with a dot) are correct; they should be owned by emmerik withgroup emmerik (or some other group if they didn't have the default group before all this); they should not have a numeric group number. Pay particular attention to .kde; the files in there need to be readable or your next login will result in a teale (bluish) screen and nothing else. Don't quit your shell with root until you have tested logging in as emmerik in another shell. You might find it difficult to get back in as root, especially if you are doing this remotely (as I did; not so smart in retrospect). Make sure you can log on, that files are owned by you, and run a command like xclock to make sure that X connections work. Finally, unmount the samba share (if mounted), remount it, and make sure you can create files in a directory in the share. You should have no problems now.
Last modified: 11/Jul/2005: Minor mods; Coniptor's solution