| 2006-09-27 12:04:48 |
disabled.user |
bug |
|
|
added bug |
| 2006-09-27 12:30:08 |
disabled.user |
description |
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this:
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, kpdf constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour. |
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this:
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
|
| 2006-09-27 12:30:08 |
disabled.user |
title |
multiple cifs issues |
(smbfs, Dapper) multiple cifs issues |
|
| 2006-09-27 23:21:16 |
disabled.user |
description |
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this:
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this:
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
|
| 2006-09-27 23:26:26 |
disabled.user |
description |
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this:
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this (w/o the newlines):
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,
dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
|
| 2006-09-27 23:28:14 |
disabled.user |
description |
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this (w/o the newlines):
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,
dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.
But my main grievance is the following:
Once a file gets it's mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
Binary package hint: smbfs
Since Dapper (which this bug-report is to be considered for) I started using cifs instead of smbfs to circumvent the issues reported in Bug#44874 and to get support for large files >2 GiB. The shares are hosted on a machine running Windows 2000.
I have multiple shares mounted via fstab, looking like this (w/o the newlines):
//server/sharename /mnt/localdir cifs rw,soft,credentials=/root/.smbcred,uid=1000,gid=1000,
dir_mode=0755,file_mode=0644,iocharset=iso8859-15
Right after boot, the (working) cifs-mounts don't show up in mtab, as already mentioned in Bug#44874. This causes double-mounts if "mount -a" will be executed, and "umount -a" won't work as supposed.
But my main grievance is the following:
Once a file gets its mode set to 444 (full read-only), it can't be changed anymore. chmod won't give any errors, it just doesn't do anything. As long as the mode is set to at least 644, chmod works fine. So once 444 is set, I have to change the read-only attribute directly on the Windows-machine back to read/write, or remount using smbfs instead of cifs to chmod.
Also, when viewing a PDF-file on such a cifs-mounted share, KPDF constantly reloads the file, which is very annoying. I have to disable the option "Watch file" to stop the constant reloading. This tells me, that somehow files on cifs-mounted shares appear "unstable" or constantly changing to some applications.
smbfs works correctly in both cases, but is to be considered obsolete and has other, major issues.
For now, I have no further clue what may be causing this behaviour.
EDIT:
tar also confirms the "unstableness" of files on cifs-shares when creating a tar-archive. Output from tar (slightly modified):
tar: /mnt/[path]/[filename]: file changed as we read it
|
|
| 2007-03-17 09:30:55 |
Urs Fleisch |
bug |
|
|
added attachment 'cifs_readoly_patch.txt' (CIFS: reset file mode when CIFS client notices that ATTR_READONLY is no longer set; reset ATTR_READONLY on Windows share when Linux client allows write permission) |
| 2007-08-14 00:50:09 |
Mathias Gug |
samba: status |
New |
Incomplete |
|
| 2007-08-14 00:50:09 |
Mathias Gug |
samba: statusexplanation |
|
Thank you for taking the time to report this bug and helping to make Ubuntu better. Can you specify which version of the kernel you're using ? |
|
| 2007-08-14 16:45:31 |
Mathias Gug |
title |
(smbfs, Dapper) multiple cifs issues |
Multiple cifs issues - CIFS: reset ATTR_READONLY on Windows |
|
| 2007-10-15 18:00:09 |
Mathias Gug |
samba: status |
Invalid |
Incomplete |
|
| 2008-01-18 15:30:34 |
Chuck Short |
samba: assignee |
|
zulcss |
|
| 2008-03-11 21:45:31 |
Leann Ogasawara |
bug |
|
|
assigned to linux-source-2.6.22 (Ubuntu) |
| 2008-03-11 21:48:45 |
Leann Ogasawara |
linux-source-2.6.22: status |
New |
Fix Released |
|
| 2008-03-11 21:49:04 |
Leann Ogasawara |
linux-source-2.6.15: status |
Incomplete |
Won't Fix |
|
